Re: RFC3484 destination address selection rule 2 is buggy

[Gabi Nakibly <[e-mail]>]

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 <[e-mail]>
To: [e-mail]
Cc: Iljitsch van Beijnum <[e-mail]>
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 <[e-mail]>
To: IETF discussion list <[e-mail]>
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
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
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
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------