[ppml] IP-v6 Needs (RE: a modified proposal 2005-8)

Howard, W. Lee Lee.Howard at stanleyassociates.com
Fri Mar 17 12:01:21 EST 2006


> -----Original Message-----
> From: Davis, Terry L [mailto:terry.l.davis at boeing.com] 
> Sent: Friday, March 17, 2006 11:33 AM
> To: Howard, W. Lee; ppml at arin.net
> Cc: Wettling, Fred
> Subject: IP-v6 Needs (RE: [ppml] a modified proposal 2005-8)
> 
> Lee
> 
> My main point is that we cannot plan for an IP-v6 world using IP-v4
> templates.  The key messages:

I think we've accepted that, and we're trying to understand what
should be done with IPv6.  RFC2119 should.


> 1) We MUST provider users (individuals/government/business) 
> with logical
> stability.  Getting new IP addresses, DNS names, and email addresses
> every time we either change providers or move will simply be
> unacceptable.  

Just because one changes does not mean the others need to change.  
That's why we have DNS and logical pointers.  The stack isn't 
monolithic.  There are several network protocols that can 
accomodate this requirement, but TCP/IP isn't designed that way.

> Without this logical stability, every communication
> service (voice/email/etc) is unstable, industry-wide initiatives (i.e.
> like power control) are not possible, and even gains the financial
> institutions hope to make with EFT systems become limited 
> (i.e. remember
> the fun of resetting all your automatic billings/payments email
> addresses last time you changed service providers?).  I know 
> this may be more an IETF issue but I'm there next week.

I've changed providers at home four times in the last two years.
My personal web site and my personal email address have been
unaffected.  I reduced my DNS TTLs, made the DNS change, and cranked
the TTLs back up.  I run my own server, but it would have been as
easy if I'd been hosted.

We're still talking about residences, right?

> 2) Assuming that any users (individuals/government/business) 
> will have a
> single service provider is completely unrealistic.  (Much of point in
> the chain below) We need to understand impacts of this to 
> IP-v6 network architectures and routing.

Define "service provider."  Is it layer 1-3 access, or layer 4-7
function, or both?  


> (I'm already dealing with this reality in the aviation industry as we
> plan for IP-v6.  The aircraft MUST be able to join to many different
> service provider networks as it moves around the world; we 
> have carriers
> that fly there aircraft literally around the world in a bit 
> over a day.
> The aircraft WILL most of the time have simultaneous links to multiple
> service providers.  An aircraft will probably have at least three
> separate networks onboard: air traffic control, airline or 
> operator, and in-flight passenger services/entertainment.)

Very few homes travel around the world in 24 hours.  Separate policies
for separate cases are acceptable.

Are you asserting that my aircraft must provide email service using
the same email address I use at home?  Same IP address?  Same E-911
address?

Do these three networks need one /64, three /64s, or one /62?

> 3) Besides government, whole industries will want address blocks that
> they manage as closed network; these may be at the regional, national,
> or global level.  Power, shipping, and aviation are some that will
> almost certainly require this.

OK.  That's allowed under current policy.  

> 4) We might as well come to terms with the idea that some of 
> these must
> be essentially irrevocable.  Can anyone envision revoking the 
> IP address
> of an aircraft that is set up in air traffic control systems 
> around the world?

I don't understand your network, so I can't comment on it.  Is
an aircraft a network host, or a router?  A site?  

Is the passenger laptop on board supposed to use an aircraft IP
address, or its home address?

If an aircraft gets an address assignment, /64 or /128 or something
else, how do you plan to route it?  That's another way of asking
how you intend to use it, and if I can't understand it, then I'll
have trouble writing a policy to cover it.

> I doubt that I can make the ARIN meeting in Montreal but I will try.

Remote participation is also an option.

Lee



More information about the ARIN-PPML mailing list