Subject: RFC3484 destination address selection rule 2 is buggy

From: Pekka Savola <[email-masked]>
Date: Fri, 14 Mar 2008 00:27:26 +0200 (EET)

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
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Thu, 13 Mar 2008 23:44:11 +0100

Perhaps some of us didn't remember but:
 - I predicted the RFC 3484 will be always at least a phase back from
  what we want.
 - I predicted too it would take a not reasonable amount of time to
  get the document published or updated.
Unfortunately both predictions were right so again I propose to make
this a BCP and *not* a standard track document.

[email-masked]

PS: I did this at the iterim meeting in Redmond, WA, in 2001...
(I also suggested to pick up DHCPv6 as the right way to perform
prefix delegation, a proposal which was strongly rejected at this time :-)
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Alain Durand <[email-masked]>
Date: Thu, 13 Mar 2008 18:49:08 -0400

+1

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 14 Mar 2008 00:56:10 +0200

Le Friday 14 March 2008 00:27:26 Pekka Savola, vous avez écrit :
> 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:
> 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).

Indeed. And this was (inconclusively) discussed at the mike during the last 
v6ops meeting. I had also asked about this a few months ago. Nobody seemed to 
care (winter vacation?):
http://www.ops.ietf.org/lists/v6ops/v6ops.2007/msg01150.html

> 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.

I think we need to "simplify" RFC3484 section 3.2 through removing the IPv4 
site-local scope there: we'd be left with only global scope (public addresses 
+ RFC1918) and link-local scope (169.254.0.0/16).

I suspect some implementors (at least Windows) already ignore §3.2 for the 
sake of reliability. I know Linux does implement ¼3.2 to the letter of the 
RFC unfortunately. And I have seen people _remove_ AAAA from their server's 
DNS records because of this issue, combined with deficient 6to4 relays.

Another problem involves incomplete implementation of RFC3484: some stacks 
apply RFC3484 for IPv6, in connect() and sendto() socket APIs, but fail to do 
RFC3484 in getaddrinfo(), and simply assume IPv6 is first, and IPv4 second. I 
suspect this applies to OSX and BSDs, and also "embedded" C run-times.

These two issues are different, though they effectively have the same result: 
favor IPv6 over IPv4, when IPv4 should be favored over IPv6 (IMHO).

-- 
Rémi Denis-Courmont

---

From: Pekka Savola <[email-masked]>
Date: Fri, 14 Mar 2008 00:56:29 +0200 (EET)

> this a BCP and *not* a standard track document.

Francis, I don't think BCP status would change this; that's still a 
IETF consensus document.  Maybe some implementations could fix their 
implementations with local hacks without as easily becoming (on paper) 
incompliant but they can already do this in any case.

However the goal of the IETF is to "make the Internet work better" 
(BCP95); I see significant value in finding out what works best and 
specifying that and revising that specification as necessary. 
Instead of leaving each vendor in the dark and invariably doing lots 
of corner cases wrong.

Maybe the critical thing that has been missing in the RFC3484 
discussions has been "have vendors already fixed this? how? which 
approach has worked and which not?"

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Mar 2008 00:09:37 +0100

In your previous mail you wrote:

=> I disagree: the procedure for BCPs is lighter and BTW there is nothing
when you look at it which justifies a standard track (we should not
promote it to a draft standard for instance :-).

=> a BCP is far more flexible if you add the term "compliant", and
it is not a surprise a best current practice can change.

I don't believe to make it a BCP will solve automagically all issues
but at least it will repair a historical error.

Thanks

---

From: Mohacsi Janos <[email-masked]>
Date: Fri, 14 Mar 2008 00:11:27 +0100 (CET)

On Fri, 14 Mar 2008, Rémi Denis-Courmont wrote:

> sake of reliability. I know Linux does implement ?3.2 to the letter of the

Not exactly. The opensource BSD implementations has "proper" RFC 3484 - 
they are treating RFC1918 addresses as global scope.

http://www.ops.ietf.org/lists/v6ops/v6ops.2007/msg01151.html

Unfortunately OSX does not have any RFC 3484 implementation.... I reported 
few months ago to Apple this issue.....

Best Regards,
 		Janos Mohacsi

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 14 Mar 2008 15:09:19 +0200

>   get the document published or updated.

IMHO, the real problem is that the various documents that added/removed 
special address ranges failed to appropriately "UPDATE" RFC3484... I'm 
thinking about Teredo, ULA, site-local deprecation and ORCHID here, but I may 
be missing some others.

---

From: Sebastien Roy <[email-masked]>
Date: Mon, 17 Mar 2008 12:13:35 -0400

> this a BCP and *not* a standard track document.

I'd agree with making it a BCP, or even of an Informational RFC.  It 
just doesn't fit the mold of a standards track document.  There are no 
two "interoperable" implementations, for example, as there is no 
interaction between two address selection algorithms on two sides of 
IPv6 communication.

-Seb

---

From: Sebastien Roy <[email-masked]>
Date: Tue, 18 Mar 2008 08:24:15 -0400

> approach has worked and which not?"

When we were working on 
http://tools.ietf.org/html/draft-ietf-v6ops-v6onbydefault-03, I 
prototyped the suggested solution of having a new rule 2.5 which avoids 
a non-link-local destination with link-local source address.  As the 
draft says, though, this is just one possible solution.  As Rémi 
mentioned on this thread, another interesting (and perhaps better) 
solution would be to simply treat rfc1918 addresses as global instead of 
site-local.  This makes sense to me since most of the time, they're 
being used with NAT to communicate to a global destination.

-Seb

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 25 Mar 2008 16:10:03 -0700

At Fri, 14 Mar 2008 00:27:26 +0200 (EET),

> (ietf-464nat is using private addresses).

I think the case of v6:{link-local (only),global} vs
v4:{site-local,global} is special and is not that harmful as long as
the network is properly configured (I know we cannot always assume
that, though).  When a link-local address is the only available
address for host, there should normally be no IPv6 default router
either.  And if an application tries to both the IPv6 and IPv4 pairs
(which I believe is the case for today's many dual-stack apps) and the
attempt with the IPv6 pair immediately fails (which should also be the
case for TCP communications on many protocol stacks, especially for
those that deprecate the "on-link by default" rule), the application
immediately falls back to the v4 pair and the user won't even be aware
of that.

Again, I'm not necessarily arguing this is negligible, but IMO we
should separate the case where the problem can be avoided by proper
operation from the case where it's impossible or very hard.  In that
sense, I think the more problematic case is (as others have already
pointed out) v6:{ULA,global} vs v4:{site-local(RFC1918),global}.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Mar 2008 07:49:42 +0200 (EET)

On Tue, 25 Mar 2008, JINMEI Tatuya / ???? wrote:
> either.

The scenario where a router advertises the default route yet does not 
advertise any prefix information (or prefix information does not set 
the autoconfig bit) is still a valid scenario (e.g., I could imagine 
DHCPv6-only deployments using this; in fact I believe if you want to 
run DHCPv6-only this is the only choice to for deploying default 
route) and it should be addressed.

Iljitsch noted in the original mail that his default route existed 
even though he moved to ietf-464nat network (the nexthop was answering 
to ping but was not sending RAs).

It is true that the case made in draft-ietf-v6ops-v6onbydefault-03 is 
already somewhat mitigated by implementations which no longer 
implement the "on-link by default" rule but that alone does not seem 
sufficient.

Is moving from one network to another (using the same interface) a 
scenario where you should purge the default route? (Even if the 
nexthop is still responsive?)  Should you purge the default route if 
the link goes down (I suspect not -- e.g. with 802.11 link with bad 
coverage this could be a problem)?

It seems to me that there are also valid scenarios where exactly the 
same problem appears in addition to many scenarios which are usually 
due to misconfiguration.  I believe our protocols should be robust 
enough to cover both valid scenarios and (if there aren't major 
drawbacks) common misconfigurations.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 27 Mar 2008 10:29:32 -0400

One general comment I have for SAS (Source Address Selection) is that
folks have listed a lot of problems in drafts to v6ops and 6man etc.,
but most problems can be filtered down to a few rather than 10 or more
different problems. Some drafts also have very contrived network design
to break SAS - such a network is not breaking anything for SAS - the
network design is broken. 

Please see in line below between "<hs>" and "</hs>".

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pekka Savola
Sent: Wednesday, March 26, 2008 1:50 AM
To: JINMEI Tatuya / ????
Cc: Iljitsch van Beijnum; [email-masked]
Subject: Re: RFC3484 destination address selection rule 2 is buggy

The scenario where a router advertises the default route yet does not
advertise any prefix information (or prefix information does not set the
autoconfig bit) is still a valid scenario (e.g., I could imagine
DHCPv6-only deployments using this; in fact I believe if you want to run
DHCPv6-only this is the only choice to for deploying default
route) and it should be addressed.

<hs>
Welcome to access concentrators service provider (vs. enterprise)
deployments, one type of which is a cable deployment, the router will
send an RA with no Prefix Information Option (PIO). Access concentrator
networks (RFC 4388) use both a router and DHCPv6. Such deployments are
really large in scale, so indeed this is a valid scenario for
consideration for any protocol design. In IETF 70 presentation to 6man,
I had also said, access concentrator deployments have hosts behind
modems as always off-link to each other.
</hs>

Iljitsch noted in the original mail that his default route existed even
though he moved to ietf-464nat network (the nexthop was answering to
ping but was not sending RAs).

It is true that the case made in draft-ietf-v6ops-v6onbydefault-03 is
already somewhat mitigated by implementations which no longer implement
the "on-link by default" rule but that alone does not seem sufficient.

Is moving from one network to another (using the same interface) a
scenario where you should purge the default route? (Even if the nexthop
is still responsive?)  Should you purge the default route if the link
goes down (I suspect not -- e.g. with 802.11 link with bad coverage this
could be a problem)?

<hs>
DNA is taking care of such an issue where a host moves from one subnet
to another. 
</hs>

Hemant

It seems to me that there are also valid scenarios where exactly the
same problem appears in addition to many scenarios which are usually due
to misconfiguration.  I believe our protocols should be robust enough to
cover both valid scenarios and (if there aren't major
drawbacks) common misconfigurations.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 27 Mar 2008 14:54:14 -0700

At Wed, 26 Mar 2008 07:49:42 +0200 (EET),

> route) and it should be addressed.

In this case I'd expect the host has a valid global address obtained
through DHCPv6, so the original assumption in this thread (link-local
only host) doesn't hold (unless you're talking about the very short
period after receiving an RA and before getting a global address via
DHCPv6).

> to ping but was not sending RAs).

I understand the case, and agree that it's weird.  But at least
conceptually, the (non-)router should set the Router flag off in NA it
sends because it doesn't act as a forwarding router on that
interface.  Then the host should be able to remove that router from
its default router list pretty quickly.  I suspect the "router" in the
464nat kept the router flag on while it's not forwarding the packet.
I feel sympathy about the behavior implementation-wise, especially if
that node acts as a forwarding router for other interfaces, but it's
still due to a non-compliant implementation behavior, rather than an
inevitable protocol-level problem.

> coverage this could be a problem)?

I admit it's difficult to solve the case with a nomadic host moving
from one link to another (but I'd say it's generally a different issue
from "v6:{link-local,global} vs v4:{site-local,global}).  In fact, the
BSD implementation I wrote tries to keep current set of addresses as
long as possible exactly to be sustainable while temporary link/router
failure.  But I also know that it does not always work and could
rather be harmful in some cases.

> drawbacks) common misconfigurations.

In general, I don't disagree.  My point is that there are several
levels of the problems, from one that is inevitable within the current
protocol to one that could be avoided by properly implementing and
operating the protocol.  The former type of problem would warrant a
protocol-level update more strongly, while the solution for the latter
of the problem may be controversial.

---
JINMEI, Tatuya

---

From: Pekka Savola <[email-masked]>
Date: Fri, 28 Mar 2008 09:25:46 +0200 (EET)

> period after receiving an RA and before getting a global address via

I'm thinking of failure modes such as the DHCPv6 server being down and 
the node being unable to get global-scope addresses, yet getting the 
default route.

One could say that this is an operational problem but my argument is 
that this would be a common-enough scenario that our protocols should 
be robust enough to route around this particular failure if there is a 
chance to do so (e.g. by default address selection choosing to use 
IPv4 instead).