Subject: Re: [MEXT] [RFC3775 changes] Wrap up on "Site-local addresses"

From: Julien Laganier <[email-masked]>
Date: Tue, 18 Mar 2008 14:42:08 +0100

Folks,

We need to wrap up this thread. As of now it seems we have consensus on 
update references to site-local addresses to unique local addresses.
Please let us know if you think this is a wrong interpretation of the 
(non-)discussion that happened so far.

-- julien & marcelo, MEXT chairs

On Monday 17 December 2007, George Tsirtsis wrote:
> All,
>
> The following text changes are dealing with the deprecated site-local
> addresses in RFC3775. See Motivation at the end of the e-mail.
>
> ---------------------------------------------------------------------
>---------------------------- OLD TEXT:
> 3.1. General Terms
> ...
>    unicast routable address
>
>       An identifier for a single interface such that a packet sent to
> it from another IPv6 subnet is delivered to the interface identified
> by that address.  Accordingly, a unicast routable address must have
> either a global or site-local scope (but not link-local).
>
> NEW TEXT:
> 3.1. General Terms
> ...
>    unicast routable address
>
>       An identifier for a single interface such that a packet sent to
> it from another IPv6 subnet is delivered to the interface identified
> by that address.  Accordingly, a unicast routable address must either
> be global IPv6 address or a unique local IPv6 address.
>
> ---------------------------------------------------------------------
>----------------------------
>
> OLD TEXT:
> 4.6. Site-Local Addressability
>
>
>    This specification requires that home and care-of addresses MUST
> be unicast routable addresses.  Site-local addresses may be usable on
> networks that are not connected to the Internet, but this
> specification does not define when such usage is safe and when it is
> not.  Mobile nodes may not be aware of which site they are currently
> in, it is hard to prevent accidental attachment to other sites, and
> ambiguity of site-local addresses can cause problems if the home and
> visited networks use the same addresses.  Therefore, site-local
> addresses SHOULD NOT be used as home or care-of addresses.
>
> NEW TEXT:
> 4.6. Unique-Local Addressability
>
>    This specification requires that home and care-of addresses MUST
> be unicast routable addresses.  Unique-local IPv6 unicast addresses
> [RFC4193] may be usable on networks that use such non-globaly
> routable addresses but this specification does not define when such
> usage is safe and when it is not.  Mobile nodes may not be aware of
> which site they are currently making it hard to prevent accidental
> attachment to other sites, resulting in possible unrechability
> between the MN and the HA, when unique-local IPv6 routable addresses
> are used as care-of addresses. Also, CNs outside the MN's own site
> are not going to be reachable when unique-local IPv6 routable
> addresses
>    are used as home addresses. Therefore, unique-local IPv6 unicast
> addresses SHOULD NOT be used as home or care-of addresses. If such
> addresses are used, however, according to [RFC4193], they are treated
> as any global unicast IPv6 address so, for the remainder of this
> specification, use of unique-local IPv6 unicast
>    addresses is not differentiated from other globally unique IPv6
> addresses.
>
> ---------------------------------------------------------------------
>----------------------------
>
> OLD TEXT:
> 10.4.2. Processing Intercepted Packets
> ...
>                                                                   
> ... Packets addressed to
>    the mobile node's site-local address SHOULD NOT be tunneled to the
>    mobile node by default.
>
> NEW TEXT (None: old text removed)
>
> ---------------------------------------------------------------------
>----------------------------
>
> OLD TEXT:
> 11.3.1. Sending Packets While Away from Home
> ...
>       o  While not at its home link, the mobile node MUST NOT use the
> Home Address destination option when communicating with link-local or
> site-local peers, if the scope of the home address is larger than the
> scope of the peer's address.
>
> NEW TEXT:
> 11.3.1. Sending Packets While Away from Home
> ...
>    o  While not at its home link, the mobile node MUST NOT use the
> Home Address destination option when communicating with link-local
> peers.
>
> ---------------------------------------------------------------------
>----------------------------
>
> OLD TEXT:
> 11.5.4. Returning Home
> ...
>                                          ...The mobile node MUST
> multicast such a
>    Neighbor Advertisement for each of its home addresses, as defined
> by the current on-link prefixes, including its link-local address and
> site-local address.
>
> NEW TEXT:
> 11.5.4. Returning Home
> ...
>                                          ...The mobile node MUST
> multicast such a
>    Neighbor Advertisement for each of its home addresses, as defined
> by the current on-link prefixes, including its link-local address.
>
> ---------------------------------------------------------------------
>----------------------------
>
> MOTIVATION:
> Site-local addresses have been deprecated (see RFC3879). According to
> this RFC, future versions of RFCs that mention site-local addresses
> should remove such references and replace them with appropriate
> alternatives. In the mean time an alternative to site-local addresses
> has been defined in RFC4193 (Unique-local IPv6 routable addresses).
> According to this RFC, these addresses have limited routability
> (typically within one or small number of sites) but they are
> otherwise treated as other global IPv6 addresses.
>
> Based on the above, the new text proposed above removes all
> references to site-local addresses and replaces them with
> unique-local IPv6 addresses as directed by RFC3879 and RFC4193.
>
> Regards
> George
>
> On Dec 15, 2007 4:25 PM, marcelo bagnulo braun <[email-masked]> 
wrote:
> > Hi George,
> >
> > El 14/12/2007, a las 16:46, George Tsirtsis escribió:
> > > Not sure if this has been discussed already so I thought I should
> > > ask first.
> > >
> > > Looking at RFC3775 I counted 8 mentions of site-local addresses,
> > > including section 4.6."Site-Local Addressability". Given the
> > > deprecated status of site local addresses (rfc3879) how do we
> > > want to handle these?
> > >
> > > Is someone else already dealing with this
> >
> > not that i am aware of
> >
> > > or shall I work on suggested
> > > text changes?
> >
> > please do
> >
> > Thanks, marcelo
> >
> > > George
> > >
> > > _______________________________________________
> > > MEXT mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/mext
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 18 Mar 2008 15:53:08 +0100

Hi,

>>    addresses is not differentiated from other globally unique IPv6

The use of a "SHOULD not" seems to be based on the hypothesis that:

- the HA will not be reachable from an ULA CoA
- the MN using an ULA as CoA might not be able to reach a CN

In companies with multiple offices (or Business Units) using different
ULA prefixes with a common routing infrastructure (site to site VPN for
instance between thoses BU):

- the HA will be reachable using an ULA as CoA (HA and MN *are* in the
  same routing domain)
- the CN from inside the enterprise network (which can be the vast
  majority of peers for a given MN in a corporate network) will be able
  to reach a MN that uses a ULA as CoA.

IMHO, when the MN is provided multiple possible CoA, it should select
the more suitable one. AFAICS (i.e. don't hesitate to correct me), the
common address selection mechanism would do the job for CoA selection in
most cases based on peer address. For a use as HoA address, there might
local reasons to use ULA.

In the end, I think the explanation on why it could fail and the "SHOULD
not" part should be removed or modified. In fact, if a more suitable
address is available to reach the HA, it could simply be used instead
of the ULA. This would make it a local decision by the MIPv6 module on
the MN based on config and local environment. And if the subnet only
advertises ULA, is there any obvious reason not to use one? 

Cheers,

a+

ps: I might have missed some messages of the thread.
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 18 Mar 2008 11:19:21 -0400

Hi Arnaud,

First of all just to make sure I understood correctly, your comment is
about the CoA only, right? i.e., you agree that a ULA should not be
used as HoA?

In any case the reason the text currently reads this way is because it
read that way for site-local addresses, so if we change it we will be
diverging from the original text rather than just fixing the issue of
site-locals being deprecated. Diverging, of course is OK if we have
good reasons for it.

I wonder then, even if the HA has a ULA (which to me sounds like a bad
idea), can the MN assume that it can use the ULA CoA to reach it?
after ULAs are not globally routable...so the fact that the same
"type" of address is available to two nodes, routing is in no way
guarantied. Also, as we know determining two nodes are in the same
site is also rather hard (one of the reasons site-locals were
deprecated).

Note, that the text uses SHOULD NOT, rather than MUST NOT, since it is
right that in specific cases ULAs could work...but probably not in the
general case.

Am I missing something?

Regards
George

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 18 Mar 2008 16:28:44 +0100

Julien Laganier wrote:
> Folks,
> 
> We need to wrap up this thread. As of now it seems we have consensus
> on update references to site-local addresses to unique local
> addresses. Please let us know if you think this is a wrong
> interpretation of the (non-)discussion that happened so far.
> 
>> The following text changes are dealing with the deprecated
>> site-local addresses in RFC3775. See Motivation at the end of the
>> e-mail.
>> 
>>  ---------------------------- OLD TEXT: 3.1. General Terms ... 
>> unicast routable address
>> 
>> An identifier for a single interface such that a packet sent to it
>> from another IPv6 subnet is delivered to the interface identified 
>> NEW TEXT: 3.1. General Terms ... unicast routable address
>> 
>> An identifier for a single interface such that a packet sent to it
>> from another IPv6 subnet is delivered to the interface identified 
>> by that address.  Accordingly, a unicast routable address must
>> either be global IPv6 address or a unique local IPv6 address.

I'm not sure a unicast routable address can be a unique local IPv6
address. rfc4193 says "These addresses are not expected to be routable
on the global Internet." So what do you mean by 'routable' address.

In my IPv4 discussions whenever I say 'routable' it means it can be
routed through Internet.  Sometimes I stress it as 'publicly routable'.
  Not sure how you use it, but just saying 'routable' sounds to not work
with ULA in my reading.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 18 Mar 2008 17:22:51 +0100

Hi George,

> about the CoA only, right? i.e., you agree that a ULA should not be

It is mainly about the CoA. But if someone inside a closed network
domain wants to make a mobile resource available *only* to people inside
that domain at a fixed address and independently of its provider prefix, 
there is no reason we should prevent that. Obviously, the location
(where on earth) of the resource does not matter here.

For instance, if the MN is a printer or a fridge, it does not make much
sense (yet) to make it globally available outside your domain.

> site-locals being deprecated. Diverging, of course is OK if we have

I understand that but having site-local deprecated and ULA promoted does
not mean we just have to query-replace things in the document. We should
also check that the statement made for site-local do still make
sense. In all other cases, i'm ok with the updates. For that particular
one, I just think that the "SHOULD not" could lead people to prevent the
use of ULA in their implementations.

> idea), can the MN assume that it can use the ULA CoA to reach it?

It will and I think it should. Using a routable one is NOT expected to
work better in that specific case.

> site is also rather hard (one of the reasons site-locals were

If your HA is using a routable address, then you (as a MN) should select
a routable address as CoA. If you have none and a ULA is available, why
not using it? That's all I am saying. 

I think that MIPv6 decision regarding address selection should be mapped
on IPv6 ones. For me, CoA selection is basically the IPv6 address
selection mechanism applied by the the MN to join its HA address. Hence
my comment. 

> right that in specific cases ULAs could work...but probably not in the

If the logic is that ULA could work (even if it is in some cases), why a
"SHOULD not". A "SHOULD not" should be used if they could make things
worse. They do not if they are used as last resort.

Cheers,

a+