Subject: SUMMARY: RE: Limiting the Use of Site-Local

From: Margaret Wasserman <[email-masked]>
Date: Sat, 02 Nov 2002 08:05:18 -0500

Posting only as an interested individual:

It definitely seems like this discussion is degenerating, but I
think we have made some useful progress in understanding what
the key issues are in this debate:

	- What are the security impacts, if any, of site
		local addresses.
	- How important are site-local addresses as a tool to
		allow site administrators to have address
		independence from their ISPs, and are there
		other ways to get this benefit?
	- What level of impact, if any, will the widespread
		use of site-local addresses have on:
			- Applications (current and future)
			- Transport Protocols
			- Security Protocols
			- Network Management Protocols
	- Should site-local addresses be placed in the DNS,
		and if so, how?
	- What level of complexity do site-local addresses
		add to router/routing protocol implementations?
	- Is there a good way to limit the use of site-local
		addresses (to non-globally attached networks,
		special uses, etc.) that will maximize the
		benefits and minimize the problems?

Did I miss any of the big issues?

Unfortunately, we haven't made much progress in resolving any
of these issues, and it doesn't look like we will resolve them
by continuing to send each other the same points in e-mail over
and over again...

I have offered to write a document that explains my thoughts on
the above issues, with a little help from my friends.  It might
also be useful for folks who believe that we should not place
any limitations on the use of site-local addresses to write a
similar document.

What do you guys think?

Margaret

--------------------------------------------------------------------
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: Allison Mankin <[email-masked]>
Date: Sun, 03 Nov 2002 23:58:18 -0500

> Did I miss any of the big issues?

Yes:
What is the *overall* complexity of site-local as represented
by the set of your questions and the lack of consensus about
its functions shown by the 100's of messages in this thread?  

When we get a feature with this much divergence and impact, it tells
us that we have a problematic design, and a good plan is often to
give it up.  Documenting the issues (your two documents) is a good
way to go for doing so, that said.

Also, could folks wear appropriate hats?  Why did you not wear your
wg chair hat in constructing the summary, Margaret?  However, I am
really not wearing an IESG hat here, since Transport AD has
no special info about this (other than being averse to complexity
as much as possible).

Allison

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 04 Nov 2002 03:17:13 -0500

Hi Allison,

>its functions shown by the 100's of messages in this thread?

Good point.  It is necessary to consider the big picture regarding
the impact of site-locals on network architecture and on overall
implementation complexity, not just the point-impacts on different
parts of the protocol stack.

>way to go for doing so, that said.

Thanks.  Hopefully by getting all of the issues (on both sides) on
the table, we can get enough information and enough input from
experts in other parts of the IETF to make the right decision.

>wg chair hat in constructing the summary, Margaret?

Because I think that I am a bit too close to the discussion to be
sure that I can do a fair job of doing that by myself.  Bob and I are
working on an official WG chair message that will propose a path
forward for the WG.

>However, I am

Actually, you could perhaps answer a couple of questions that we had
about the Transport area and site-locals.  Or, if you don't know the
answers, could you refer us to folks who might?

There is a draft which describes how SCTP could deal with IPv6
site-local unicast addresses, authored by Randall Stewart and
Steve Deering.  It can be found here:

http://www.ietf.org/internet-drafts/draft-stewart-tsvwg-sctpipv6-01.txt

Do you know if the Transport area WG will be considering this draft
as a work item?  Will it be discussed in Atlanta?

Do you know if there is any work underway to determine how SIP
would deal with IPv6 site-local addressing?

Thanks,
Margaret

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 18 Nov 2002 15:46:41 +0100 (CET)

> Posting only as an interested individual:

Me to.
 
> 			- Network Management Protocols

Add mobile-ip to the above list.

Having once thought that site-local addresses in sites that have global
prefixes was reasonable idea, I did go down the path of trying to figure out
what it would take to allow mobile nodes to use site-local addresses.

Since mobile nodes typically don't know the "range" of their mobility
up front, this seems to lead to a desire to have a mobile node use site-local
addresses when in its home site and not have that communication fail when
the node moves outside its home site. (If this isn't provided the result
would probably be that all mobile nodes will only be configured with global
addresses.)

An outline of what it takes to do this was in previous versions of
the long expired draft-ietf-ipngwg-site-prefixes draft.
It seemed like by adding explicit support for this in correspondent
nodes, home agents, and mobile nodes it could be made to work.
But, just like applying thrust to make pigs fly, it might not be a good idea.

At some WG meeting a long time ago there was rough consensus to not have
this complexity (which was the right answer in my opinion). 
But a result of this is that nodes that might be mobile and use mobile ipv6
should not be configured with a site-local address (unless it is
somehow known that they will not move outside of their home site).

Thus any claimed benefits of site local addresses don't apply to mobile nodes
AFAI understand. For instance, the claimed security benefits when configuring
nodes to only accept packets from site-local addresses would cause
a problem for mobile nodes,

  Erik

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 18 Nov 2002 07:17:11 -0800

Hello Erik,

I have a minor comment on your note, without taking away from
its main thrust.

> would probably be that all mobile nodes will only be configured with global

It should be possible for a mobile node to use a site-local prefix as long
as it only ever roams within the site.  This seems to go along with the
proposal that site-local prefixes should only be used in domains that are
disconnected from the Internet.  If a mobile node has a global home address,
it should use that global address all the time, I reckon.  Otherwise, if it
only has a site-local address, then by definition it is only addressable at
that site.  Users of such equipment should be made aware of that limitation.

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 18 Nov 2002 16:39:20 +0100 (CET)

> that site.  Users of such equipment should be made aware of that limitation.

Agreed when either site-locals or global addresses are used in the site.

But unless site-locals are restricted there is a case when both global
and site-locals are used at the same time and then presumably it would be
possible to configure a mobile node with both a global and site-local
address. In that case it is less clear what makes sense I think.

  Erik

---

From: Greg Daley <[email-masked]>
Date: Tue, 19 Nov 2002 03:08:09 +0000

Hi Erik,

there's a set of cases where the MN uses Localized mobility management
such as HMIPv6 and can use only site locals within a set of access
networks.

The MN is reachable through a regional care-of-address which is
globally scoped.  In this case, communication within the access network
uses the site-local address for communication, and global communication 
relies upon tunnelling to the HMIPv6 LMM Agent.  Similarly, site-locals
from the home-network are tunnelled over the global Internet.

Simple classification based on received/transmit interface (virtual
tunnel
or phy interface) could be used to distinguish between site-local zones.

As far as normal non LMM managed MIPv6 goes, it's pretty clear that
using
site-locals for a care-of-address is only valid if you're not connected
to the Internet.  Home network site-locals once again are tunnelled, and
may be distinguished from more mundane traffic.

I'm not sure if this is complete, but I don't see it's that 
problematic.

Greg Daley

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 18 Nov 2002 19:02:05 +0100 (CET)

> I'm not sure if this is complete, but I don't see it's that 

Which problem are you trying to solve here to which the solution
is to use site local addresses?

I don't see why using site local addresses in the context of local mobility
has any benefits, but perhaps I'm missing something.

The cases when site-local addresses don't offer any benefits and they
don't cause any additional complexity or problems are not interesting to
discuss since it doesn't help folks understand the tradeoffs between
different levels of support for site-locals.

  Erik

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 18 Nov 2002 13:30:29 -0500

Erik Nordmark wrote:
> > It should be possible for a mobile node to use a site-local 
> prefix as 
> > long as it only ever roams within the site.  This seems to go along 
> > with the proposal that site-local prefixes should only be used in 
> > domains that are disconnected from the Internet.  If a 
> mobile node has 
> > a global home address, it should use that global address 
> all the time, 
> > I reckon.  Otherwise, if it only has a site-local address, then by 
> > definition it is only addressable at that site.  Users of such 
> > equipment should be made aware of that limitation.
> 
> But unless site-locals are restricted there is a case when 
> both global and site-locals are used at the same time and 
> then presumably it would be possible to configure a mobile 
> node with both a global and site-local address. In that case 
> it is less clear what makes sense I think.

In terms of packet format, and registration with the HA, I see no reason
for SL to create any confusion. It is just one of the addresses that
could map to the current care-of address. The point the might be
confusing is the ability of the mobile node to detect that it is no
longer in the site. This should not be particularly difficult in the
case where the RA no longer contains a SL or global prefix for the HA,
because this is a good indication that the node is 'no longer in
Kansas'. The problem case is where the RA contains only SL. Is this the
home site where the global prefix went away or not? Since there is no
global prefix for the care-of, it would be hard to establish a mip-v6
ha/coa mapping. This does not mean SL fails in the case of the mobile
node, only that nodes that move between SL-enabled networks might need
to look for other hints to decide when they are no longer 'home'. 

Tony

---

From: Greg Daley <[email-masked]>
Date: Tue, 19 Nov 2002 05:36:59 +0000

Hi Erik,

Mobileip and NEMO scenarios may benefit from using only 
site locals, if global addresses in the access networks
are unavailable or invalid/off-topology.  

In this case, e-to-e global connectivity is available through the 
mobility management agent, which provides a global address or 
addresses at the edge of the local mobility domain.

It can also be used to enforce localized management policy.
(all packets are reverse tunnelled to the mobility management
agent).

Still, these may not be sufficiently good reasons to place 
these ideas into discussion.

I didn't intend to cloud the waters, but I can't see
many other uses for site-local in the mipv6 access network. 

Greg

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 18 Nov 2002 20:55:54 +0100 (CET)

> Kansas'. 

What prefix length are you advocating to use when comparing?
There is no reliably way a MN can know what global prefixes (with lengths)
are used in its site.

But even if you solve that, you need think think about Route Optimization
issues when the CN, HA, and MN can be in any set of sites.

> The problem case is where the RA contains only SL. Is this the

That is a problem I hadn't thought about.
Seems like we are finding new problems in this space ...

  Erik