Subject: Re: RFC3484 destination address selection rule 2 is buggy

From: Gabi Nakibly <[email-masked]>
Date: Tue, 18 Mar 2008 05:10:13 -0700 (PDT)

Pekka,
I agree that the scenario that was presented in http://tools.ietf.org/html/draft-ietf-v6ops-v6onbydefault-03
is very problematic. However, I do not think that the root of the problem is the destination address selection rule 2. As you mentioned, the source-destination pair v6:{link-local,global} will most likely not work. Hence, it should not be chosen even if it is the only pair available (it is preferable to give an immediate destination unreachable indication than to try in vain for several seconds to reach the destination). So altering the dest. address preference rules is not the way to go. 
IMHO, the root problem is the selection of the candidate source addresses (sec. 4 in RFC3484). The candidate set must not include a source address which its zone does not contain the interface identified by the destination address. This is a direct consequence of the forwarding rule in RFC4007 sec. 9 (http://tools.ietf.org/html/rfc4007#section-9) second bullet :
      "If transmitting the packet on the chosen next-hop interface would cause the packet to leave
      the zone of the source address, i.e., cross a zone boundary of the
      scope of the source address, then the packet is discarded."
Determining whether the destination address is in the zone of a source address can be tricky. However, it is fairly easy in the common case where the source address is link-local and the destination address is global. If the latter is not on-link, than it is not in the zone of the link-local source address and this source address should not be included in the candidate set. If the above rule will be applied in the scenario of http://tools.ietf.org/html/draft-ietf-v6ops-v6onbydefault-03, the candidate set of the v6 address will be empty and therefore it will be avoided by destination address selection rule 1.
 
Gabi

----- Original Message ----
From: Pekka Savola <[email-masked]>
To: [email-masked]
Cc: Iljitsch van Beijnum <[email-masked]>
Sent: Friday, March 14, 2008 12:27:26 AM
Subject: RFC3484 destination address selection rule 2 is buggy

FYI,

While the default router "persistence" is an interesting observation, the more 
interesting one is why the default address selection algorithm pick 
source,destination pair of v6:{link-local,global} which is almost certain not 
to work instead of v4:{site-local,global}
(ietf-464nat is using private addresses).

This issue was first reported about 5 years ago by Alain Durand et al and yet 
there is no fix yet (and no mention in the default address selection problem 
statement), see section 2 of:
http://tools.ietf.org/html/draft-ietf-v6ops-v6onbydefault-03

The main problem is destination address selection rule 2 which requires that 
source and destination address scopes must match (which in the case of v4 
private and global addresses is not a very useful comparison given the 
prevalence of NAT).

Maybe we need a more systematic approach to deal with RFC3484 issues (as in, a 
numbered list of all the problems noted) instead of doing a nice new features 
to have PPT slideshow every IETF meeting.

---------- Forwarded message ----------
Date: Thu, 13 Mar 2008 09:55:05 -0400
From: Iljitsch van Beijnum <[email-masked]>
To: IETF discussion list <[email-masked]>
Subject: IPv6 router when switching wifi networks

I think this is of interest to more people than just the 71attendees
and I can't edit the wiki with Safari, so I'm sending it to this list:

When I switch from the IPv6-only wifi network to the v4v6v4 NAT
network, everything that has an IPv6 address in the DNS stops working.
Turns out that my Mac tries to get at these destinations over IPv6,
even though it doesn't have an IPv6 address. However, it DOES have an
IPv6 default route:

$ route get -inet6 default
    route to: ::
destination: ::
        mask: default
      gateway: fe80::20b:bfff:fea9:7054%en1
    interface: en1
        flags: <UP,GATEWAY,DONE,STATIC,PRCLONING>

This happens to be the same router that's on the v6only network. And
it's reachable on the v4v6v4 nat network, too:

$ traceroute6 www.ietf.org
traceroute6 to www.ietf.org (2001:1890:1112:1::20) from fe80::21b:
63ff:fe02:3c13%en1, 30 hops max, 12 byte packets
  1  fe80::20b:bfff:fea9:7054%en1  1.698 ms  1.431 ms  1.052 ms
  2  * * *
  3  *^C

Further inspection shows it doesn't send out any router advertisements
on the v4v6v4 nat network:

09:45:59.414798 IP6 nirrti.local > ff02::2: ICMP6, router
solicitation, length 16
09:45:59.508252 IP6 nirrti.local > ff02::2: ICMP6, router
solicitation, length 16
09:46:00.903133 IP6 nirrti.local > ff02::2: ICMP6, router
solicitation, length 16
09:46:03.714192 IP6 nirrti.local > ff02::2: ICMP6, router
solicitation, length 16
09:46:08.374871 IP6 nirrti.local > ff02::2: ICMP6, router
solicitation, length 16
09:46:16.406312 IP6 nirrti.local > ff02::2: ICMP6, router
solicitation, length 16
09:46:24.581632 IP6 nirrti.local > ff02::2: ICMP6, router
solicitation, length 16

But this seems to be the culprit:

09:46:27.945222 IP6 nirrti.local > fe80::20b:bfff:fea9:7054: ICMP6,
neighbor solicitation, who has fe80::20b:bfff:fea9:7054, length 32
09:46:27.946167 IP6 fe80::20b:bfff:fea9:7054 > nirrti.local: ICMP6,
neighbor advertisement, tgt is fe80::20b:bfff:fea9:7054, length 24

Apparently, MacOS 10.5.2 tries to see if the router from the previous
wireless network is still present, and if it is, it will keep the
default route up. But because the IPv6 addresses were removed from the
system when changing networks and now new prefix was advertised, it
doesn't work.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Tue, 18 Mar 2008 05:33:15 -0700

On Mar 18, 2008, at 5:10 AM, Gabi Nakibly wrote:

> Determining whether the destination address is in the zone of a  
> source address can be tricky. However, it is fairly easy in the  
> common case where the source address is link-local and the  
> destination address is global. If the latter is not on-link, than  
> it is not in the zone of the link-local source address and this  
> source address should not be included in the candidate set. If the  
> above rule will be applied in the scenario of http://tools.ietf.org/ 
> html/draft-ietf-v6ops-v6onbydefault-03, the candidate set of the v6  
> address will be empty and therefore it will be avoided by  
> destination address selection rule 1.

Speaking for myself, there is a simpler rule in that special case  
that imght be instructive in the ULA case.

There is no sense in using a link-local address as a source address  
unless one is sending to someone on the same LAN. Hence, there is no  
sense in suing a link-local address as the source if one cannot also  
use one in the destination.

Similarly, there is no sense using a ULA source address unless the  
destination is in the same ULA. If the destination is a global  
address it might or might not be able to reply, but the sender can't  
tell.

Hence, in sender address choice:
   - use a link-local source address if and only if the destination  
is a link-local address
   - use a ULA source address if and only if the destination is a ULA  
in the same prefix
   - otherwise, use a global address

---

From: Sebastien Roy <[email-masked]>
Date: Tue, 18 Mar 2008 09:40:25 -0400

>    - use a link-local source address if and only if the destination  

In RFC3484-speak, do you mean that if the destination is global, then the 
candidate set must not contain link-local?  That makes sense to me.

Otherwise, if you're referring to a new selection rule for either source 
address selection or destination address ordering, there is no way to 
express "use a ... if and only if ...", as the language of a rule is, 
"prefer x over y".

>    - otherwise, use a global address

So far, there are at least three ways to address this problem:

1. destination address ordering rule 2.5 that prefers destinations with 
non-link-local source addresses.

2. treat rfc1918 as global scope.

3. in source address selection, the candidate set should be comprised of 
addresses of equal or greater scope than the destination. (this isn't 
exactly how it has been expressed, but that's how I'm interpreting what's 
been said at the moment.)

IMO, #2 seems like the simplest approach, and #3 is also not a bad idea. 
  #1 is probably overkill.  I'd consider implementing both #2 and #3.

-Seb

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Mar 2008 12:56:39 +1300

Fred,

> On Mar 18, 2008, at 5:10 AM, Gabi Nakibly wrote:
...

> address it might or might not be able to reply, but the sender can't  

No, that isn't the case in at least two instances I can think of

1. An enterprise network whih for historical reasons is running
more than one ULA prefix - I would expect them to be fully
routed (and longest match would work).

2. An enterprise which is running a VPN with a business partner,
and is routing the ULA across that VPN.

So...

>    - use a link-local source address if and only if the destination  

Clearly.

>    - use a ULA source address if and only if the destination is a ULA  

I think that is broken. There's a reason ULAs are defined as global
addresses.

    Brian

---

From: Fred Baker <[email-masked]>
Date: Fri, 28 Mar 2008 01:00:30 -0700

> I think that is broken. There's a reason ULAs are defined as global

but they are *not* global addresses. If they were, they would be UGAs,  
not ULAs.

What they are is local addresses with undefined scope. Routing may or  
may not be stable between a system using a ULA and another system that  
doesn't have an address in that prefix. The only way for the system  
using the ULA to know is for it to have configuration that tells it,  
or to receive a message from the remote system (one that it can know  
with assurance doesn't have a spoofed source address) that is sent to  
its ULA address.

Hence,if it is selecting an address, it should go by the Robustness  
Principle. It should accept a message from the peer sent to its ULA  
address, but it should itself do something it has assurance will work  
correctly. It should only send from a ULA if it knows that the peer  
has an address in the same prefix, and it can only know that by  
configuration or by observation that the peer is using the same prefix.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Fri, 28 Mar 2008 11:33:43 -0700

Fred,

> but they are *not* global addresses. If they were, they would be UGAs,

The are defined as having global scope.   They are unique and valid  
globally.  They usually don't have global reachability.  From RFC4193:
>> 3.3. Scope Definition
>> By default, the scope of these addresses is global. That is, they  
>> are not limited by ambiguity like the site-local addresses defined  
>> in [ADDARCH]. Rather, these prefixes are globally unique, and as  
>> such, their applicability is greater than site-local addresses.  
>> Their limitation is in the routability of the prefixes, which is  
>> limited to a site and any explicit routing agreements with other  
>> sites to propagate them (also see Section 4.1). Also, unlike site- 
>> locals, a site may have more than one of these prefixes and use  
>> them at the same time.
The issue is about reachability, not scope defination.

> configuration or by observation that the peer is using the same  

I think I am in general agreement of the consequences, but it isn't  
about scope, it is about reachability.  Anytime there is a a choice of  
addresses to use, the same issue come to play.  It's hard to know  
about reachability with out prior knowledge or trying it out and  
seeing what works.  This applies to ULAs and other global scope  
unicast addresses, IPv4 and IPv6 addresses, etc., etc.

Bob

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 28 Mar 2008 15:51:31 -0400

I totally agree with Bob. Thanks to him for also providing the
references.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bob Hinden
Sent: Friday, March 28, 2008 2:34 PM
To: Fred Baker (fred)
Cc: Iljitsch van Beijnum; IETF IPv6 Mailing List; Brian E Carpenter;
Pekka Savola
Subject: Re: RFC3484 destination address selection rule 2 is buggy

Fred,

The are defined as having global scope.   They are unique and valid  
globally.  They usually don't have global reachability.  From RFC4193:
>> 3.3. Scope Definition
>> By default, the scope of these addresses is global. That is, they are

>> not limited by ambiguity like the site-local addresses defined in 
>> [ADDARCH]. Rather, these prefixes are globally unique, and as such, 
>> their applicability is greater than site-local addresses.
>> locals, a site may have more than one of these prefixes and use them 
>> at the same time.

I think I am in general agreement of the consequences, but it isn't
about scope, it is about reachability.  Anytime there is a a choice of
addresses to use, the same issue come to play.  It's hard to know about
reachability with out prior knowledge or trying it out and seeing what
works.  This applies to ULAs and other global scope unicast addresses,
IPv4 and IPv6 addresses, etc., etc.

Bob

---

From: Fred Baker <[email-masked]>
Date: Fri, 28 Mar 2008 20:01:46 -0700

On Mar 28, 2008, at 12:51 PM, Hemant Singh (shemant) wrote:

> about

By this line of reasoning, scope is irrelevant. The only thing that  
the Robustness Principle would guide towards is the ability to  
exchange datagrams and open state with one's peer.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Mar 2008 10:06:08 +1300

On 2008-03-29 16:01, Fred Baker wrote:
> By this line of reasoning, scope is irrelevant. The only thing that the
> Robustness Principle would guide towards is the ability to exchange
> datagrams and open state with one's peer.

I think the problem is that scope, if you think of it as a set of
concentric circles of reachability, is a delusion.

Specifically,

On 2008-03-28 21:00, Fred Baker wrote:

> It should only send from a ULA if it knows that the peer has an address
>  in the same prefix

Not so. The peer might, for example, have a prefix in
another private prefix, such as another ULA prefix, that
just happens to be reachable within the same enterprise
or via VPN. Expressing that reachability via a scope
suffix or by any kind of rule seems very hard. Treating
ULAs as global and relying on longest match to do the
right thing is probably the best we can do.

     Brian

---

From: Bob Hinden <[email-masked]>
Date: Mon, 31 Mar 2008 10:10:12 -0700

Fred,

> exchange datagrams and open state with one's peer.

Yes (with the obvious exception of IPv6 link-local addresses).  I  
think that without some sort of active confirmation, anything else we  
can do is a hint as to the best order of trying out a source and  
destination address pair.

Bob

---

From: Fred Baker <[email-masked]>
Date: Mon, 31 Mar 2008 11:22:35 -0700

On Mar 31, 2008, at 10:10 AM, Bob Hinden wrote:
> think that without some sort of active confirmation, anything else  
> we can do is a hint as to the best order of trying out a source and  

That is of course what I'm getting at. A host doesn't participate in  
routing, and any assertion that "well, he could use prefix foo with  
prefix bar if he knows that one can reach the other" presumes either  
configuration or routing knowledge.

Absent either configuration or routing knowledge of more specific  
reachability, two interfaces that are using the same prefix (could be  
link-local prefix, ULA prefix, or global prefix) can talk with each  
other using the common prefix. Two devices that don't share a prefix  
shouldn't know about addresses the peer has that they can't use. Note,  
however, that DNS purists will tell you that there should be no  
question of address domains - they simply report the records they have  
on file, which may yield some addresses not reachable via ambient  
routing. Therefore, especially given the DNS purist model, such  
systems need to assume that either they connect from a global address  
to global address or try the cross product of their two address sets  
to see what works. If you don't like the latter - and yes, there are  
good reasons to not like it - you're stuck with the former.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------