Subject: RE: Consensus on Site-Local Addressing

From: "Michel Py" <[email-masked]>
Date: Wed, 9 Apr 2003 21:01:07 -0700

Fred,

> A fundamental question here is whether the disconnected/
> intermittently connected networks will require subnetting
> internally. When subnetting is not required, link-local
> addressing (i.e., FE80::/10) may be enough.

There are many cases where these sites would indeed require local
subnetting.

Michel.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 10 Apr 2003 10:46:23 -0700

Michel,

> There are many cases where these sites would indeed require local

Is your statement based on proven fact or best current practices and/or
conventional wisdom which may/may not be based on proven fact? I am not
trying to be critical/sarcastic; just pointing out that we may need to
examine long-held beliefs as we find a way forward.

Regards,

Fred Templin
[email-masked]

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 10 Apr 2003 11:29:51 -0700

Fred L. Templin wrote:
> ...
> Is your statement based on proven fact or best current 
> practices and/or conventional wisdom which may/may not be 
> based on proven fact? 

See draft-hain-ipv6-sitelocal-00.txt, the research ship example as one
real case where a multi-subnet network intermittently attaches to
different providers. Other vehicle types (airplanes in particular)
already have multiple subnets, and will attach to different providers
over time. 

> I am not trying to be 
> critical/sarcastic; just pointing out that we may need to 

Yes we need to examine beliefs, like the concept that applications can
blindly pass topology locators around, or that multi-faced DNS doesn't
exist because the IETF refuses to deal with it. The reality of the
network is that there are addresses that are only useful in a particular
routing scope, and it is inappropriate for applications or
infrastructure to pass those outside the scope of relevance. 

Tony

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 11 Apr 2003 11:03:26 -0400

>already have multiple subnets, and will attach to different providers

This is exactly the type of problem that the nemo working group is
chartered to address, so people interested in working on this
problem should start following the nemo group.  I don't believe
that they are far enough along yet to have determined whether any
special type of addressing is needed to solve this problem.

It also seems possible that the results of the nemo work will apply
to intermittently connected SOHO networks, but I don't think that
is their main thrust.

I haven't actually been following nemo, but I probably should...

Margaret

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 11 Apr 2003 12:05:23 -0700

the nemo solution tries to provide session continuity for
hosts in the mobile network. it is obvious that hosts inside
the mobile network have to use global IPv6 addresses if they
are going to connect to any random CN (correspondent node, as
defined in Mobile IP). but if a host inside the mobile network
wants to communicate to a host inside the home network (every
nemo network has a home link) using site local addresses, the
nemo solution wouldnt be preventing it. and ofcourse hosts
inside the mobile network can communicate with each other with
site local addresses if they wish. the nemo solution wouldnt
care about it.

the mobile router in the mobile network has to ensure that
packets with site local addresses dont leak into the visited
network. it needs to enable some filtering, based on whether
it is on the home link or on the visited link.

Vijay

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 14 Apr 2003 14:47:22 +0200 (CEST)

> already have multiple subnets, and will attach to different providers

Tony,

I stated some disagreement with the research ship example being a case
where site-locals would help on April 4th. Email included below since I didn't
find a http archive for the list which provides URLs for each email.

I didn't see a response from you.

  Erik

>----- Begin Included Message -----<

Date: Fri, 4 Apr 2003 13:38:28 +0200 (CEST)
From: "Erik Nordmark" <[email-masked]>
Subject: RE: site-locals
To: [email-masked]
Cc: "'Erik Nordmark'" <[email-masked]>, [email-masked],
[email-masked], [email-masked]

> It is not a red herring. Input sent to me for the requirements doc:

But this case is exactly the same as what I categorized as #1 in my list - 
isolating communication local to the site from site renumbering. The only added
twist is that site renumber occurs when the site attaches and detaches from
the Internet.

> Research ships at sea intermittently connect via INMARSAT, or when in
> port, the shipboard network is connected to shore via Ethernet.

Looking at your resarch ship case a bit more in detail it occurs
to me that even using site-locals plus globals while connected doesn't
necessarily protect the local communication. The introduction of the 
global prefix/addresses when the ship is connected might very well
trigger different address selection behaviors in the stack or in the
applications. Thus it seems like the robustness provided by site-locals
only apply to communication established (and addresses selected)
before the global prefix is introduced. Later communication is subject
to any bugs or poor interaction in the address selection domain - something
that is bound to have some corner cases due to its complexity.
(Note that this is a property that applies to #1 in my list that I've
previously not realized.) While the effect of this probably is less than
the effect of renumbering the ships network each time it attaches to the
Internet, it still doesn't isolate the ships internal network from
being attached to the Internet when site-locals are used as you propose.

So if I were to design this ship I'd use neiether renumbering at
attachment time nor site-locals. Instead I'd have the research ship get
a stable prefixe (a few /64's might suffice) from the organization that runs 
it which are globally unique and can be used whether the ship is connected
or disconnected. This completely isolates the addressing of the ship internals 
from whether it is connected or disconnected; the only difference is the when
disconnected off-ship destinations are unreachable. When it gets connected
tunnel(s) need to be established back to the research organization in order
for routing to work. Such tunnels could be cobbled up today with some existing
tunnel establishment mechanism, and the Nemo WG is working on an IETF standard
for such tunnel establishment. So if you want internal stability you have to
pay by having less efficient routing - going bidirectionally over the tunnel
to "home" - no free lunch.

If you believe in Mobile IPv6 route optimization you might also
believe that the Nemo work can be extended to provide route optimization
to/from correspondent nodes in the Internet at large (by reusing the
MIPv6 approach). I personally think the utility of this remains to
be proven, but if it is it would help with the routing inefficiencies caused
by routing.

So once again, this is not a case where I think site-locals help.

   Erik

>----- End Included Message -----<

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 18 Apr 2003 09:05:57 -0700

Erik Nordmark wrote:
> I stated some disagreement with the research ship example
> being a case where site-locals would help on April 4th. Email 
> included below since I didn't find a http archive for the 
> list which provides URLs for each email.
> 

Sorry, I missed it.

> Cc: "'Erik Nordmark'" <[email-masked]>,
> [email-masked], [email-masked], [email-masked]
> 
> isolating communication local to the site from site 
> renumbering. The only added twist is that site renumber 
> occurs when the site attaches and detaches from the Internet.

To different service providers, so the ideas promoted about telling ISPs
they must allocate the same space to a given network don't work.

> Looking at your resarch ship case a bit more in detail it
> occurs to me that even using site-locals plus globals while 
> connected doesn't necessarily protect the local 
> communication. The introduction of the 
> global prefix/addresses when the ship is connected might very 
> well trigger different address selection behaviors in the 
> stack or in the applications. 

Not if they follow the addr selection rules as currently written.

> Thus it seems like the
> robustness provided by site-locals only apply to 
> communication established (and addresses selected) before the 
> global prefix is introduced. Later communication is subject 
> to any bugs or poor interaction in the address selection 
> domain - something that is bound to have some corner cases 
> due to its complexity. (Note that this is a property that 
> applies to #1 in my list that I've previously not realized.) 

Bugs aside, if the 'smallest scope' rule is applied, there is no issue
with protecting the local communication.

> While the effect of this probably is less than the effect of
> renumbering the ships network each time it attaches to the 
> Internet, it still doesn't isolate the ships internal network 
> from being attached to the Internet when site-locals are used 
> as you propose.

I believe it does.

> 
> So if I were to design this ship I'd use neiether renumbering
> at attachment time nor site-locals. Instead I'd have the 
> research ship get a stable prefixe (a few /64's might 
> suffice) from the organization that runs 
> it which are globally unique and can be used whether the ship 
> is connected or disconnected. This completely isolates the 
> addressing of the ship internals 
> from whether it is connected or disconnected; the only 
> difference is the when disconnected off-ship destinations are 
> unreachable. When it gets connected
> tunnel(s) need to be established back to the research 
> organization in order for routing to work. 

While tunnels are probably acceptable for bulk file transfer, I doubt
anyone would accept it for interactive/VoIP use when the tunnel endpoint
is halfway around the world.

> Such tunnels could
> be cobbled up today with some existing tunnel establishment 
> mechanism, and the Nemo WG is working on an IETF standard for 
> such tunnel establishment. So if you want internal stability 
> you have to pay by having less efficient routing - going 
> bidirectionally over the tunnel to "home" - no free lunch.

I agree there is no free lunch, but there is no reason to drop the
internal use prefix just because a renumbering event added a routable
one. The cost is the complexity to keep straight which prefix is local
use vs. routable (not too hard with a well known prefix, but still
possible with other tools to differentiate them).

> 
> If you believe in Mobile IPv6 route optimization you might
> also believe that the Nemo work can be extended to provide 
> route optimization to/from correspondent nodes in the 
> Internet at large (by reusing the MIPv6 approach). I 
> personally think the utility of this remains to be proven, 
> but if it is it would help with the routing inefficiencies 
> caused by routing.
> 

Site locals as currently defined are more efficient for this use than
the alternatives. That does not mean it is the only approach, just that
the simple 'must change addresses on connect' BS is completely invalid.

Tony