Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?]

From: "Michel Py" <[email-masked]>
Date: Tue, 1 Apr 2003 21:08:43 -0800

Brian,

> Brian Zill wrote:
> In the case you list below, host1 and host2 will both have
> two addresses.  One set of those addresses share a subnet
> and by virtue of longest prefix match will be the pair
> picked by the source/destination address selection rules.
> So host1 and host2 will happily communicate without
> needing to traverse a router.

<side note>
I re-read what I have posted and a copy/paste casualty got rid of "the
internal" in front of "router" which equates un-necessary
encapsulation/decapsulation.
</side note>

There are two points about this:

1. The source host knowing all addresses about the destination host.
2. Where it really breaks.

1. The source host knowing all addresses about the destination host.
--------------------------------------------------------------------
There is some truth in what you wrote, but unfortunately you assume that
the source host will acquire both addresses of the destination host.
Without bad intents, I will remind you that there are five ways a v4
Microsoft host in the majority of deployed cases can locate another host
by name, as defined by option #46 in DHCP and complemented by local
options:

- hosts files
- lmhosts files
- Broadcast
- WINS
- DNS

Again, keep in mind that I am not one of these guys that scream
"Microsoft sucks" each time they have an opportunity nor one that says
that Windows is not a "real" operating system (it is strangely real for
an "unreal" product to have 90% of the market, pun intended).

That being said, when one has five different ways to resolve a name to
an IP address, you will allow me to see multiple reasons for SNAFUs.

2. Where it really breaks, with the knowledge of 1. above:
----------------------------------------------------------
> In other words: it is quite all right for nodes to have a
> 6to4 pseudo-interface enabled even if another link to which
> they are connected has a native prefix including those within
> 2002::/16. The RFC is fine as is.

You missed the main point although I will concede that I failed to
explain it in sufficient detail. Here it is:

a) By re-reading the example pasted below you will understand that the
entire site uses 2002:xxyy:zz01::/48 as its prefix, and there are
multiple reasons for this including a stable DNS.

b) Host2 is a server of some kind. Host2 has two IPv6 addresses as you
mentioned, one being a statically configured IPv6 address:
   b1> host2: 2002:xxyy:zz01:0001:2::2/64
   This is a perfectly valid modified-EUI-64 address with the "u" bit
set.
And the other one being the 6to4 address of the pseudo interface:
   b2> host2: 2002:xxyy:zz67:????:HST2:I:I:D/64

It is clear to me that it is highly desirable that the only IPv6 address
present in DNS for outside resolution is the first one, both for the
reason that a v4 address change should not trigger a v6 address change
(minor) and more because good practice will deny protocol 41 ingress for
any address other than x.y.z.1 (major).

Here's where it breaks:
- A host from the outside wants to communicate to host2.
- The host outside picks 2002:xxyy:zz01:0001:2::2 as the destination
address. Even if 2002:xxyy:zz67:????:HST2:I:I:D is also published in DNS
you can't guarantee that it won't happen as the longest match rule does
not apply here, note that there are no subnet masks anymore.
- Host2 receives the traffic and wants to reply.
- Host2 SAS picks 2002:xxyy:zz01:0001:2::2/64 as the source address for
the reply (a no-brainer, since the communication originated to this
address)
- Host2 has three IPv6 routes (non including link-local)
  - The default route pointing to the router, acquired by
    stateless autoconfig.
  - 2002:xxyy:zz01:0001:2::/64 directly connected.
  - 2002::/16 on the pseudo-interface.
==> The longest match rule sends the packet to the pseudo-interface
where the RFC3056-compliant implementation dumps it in the bit bucket.
==> Even if the implementation is not RFC-3056 compliant good chances
are that an access-list somewhere on the edge will dump the traffic
because protocol 41 is allowed only from and to x.y.z.1.

I know what you're going to reply: just configure a static route for
2002:xxyy:zz01::/48 pointing to the router. Yes, it would solve one of
the problems, and yes it also stinks big time. Configuring a static IP
address is one thing, configuring static routes in hosts is quite
another one.

Sorry I did not include this in my previous post, I was trying to make
it short and it was not a good idea. More comments?

Michel.

> > Brian Carpenter wrote:
> > Some hosts can support such a pseudo-interface, but having
> > it on by default is a problem IMHO.
> > RFC 3056 mainly talks about routers and strongly implies
> > what Michel says, but that MUST NOT is not in any RFC.
> 
> It should be, but is implied anyway because that's the only 
> way it can work.
> 
> Example: My IPv4 prefix is x.y.z.0/24
> I have four subnets:
> - x.y.z.0/26
> - x.y.z.64/26
> - x.y.z.128/26
> - x.y.z.192/26
> 
> My router is x.y.z.1 and x.y.z.65 and x.y.z.129 and x.y.z.193 
> host1 is x.y.z.66 host2 is x.y.z.67
> 
> I migrate to IPv6 using 6to4. I decide that my IPv6 prefix is 
> 2002:xxyy:zz01::/48. Makes sense as the router is going to be 
> the 6to4 gateway for the site.
> 
> I will dual-stack. My subnets now are:
> 
>                  Routing prefix|Site|IID
>                                |topo|
> - x.y.z.0/26     2002:xxyy:zz01:0000::/64
> - x.y.z.64/26    2002:xxyy:zz01:0001::/64
> - x.y.z.128/26   2002:xxyy:zz01:0002::/64
> - x.y.z.192/26   2002:xxyy:zz01:0003::/64
>                                |    |
> 
> 
> My hosts IPv6 addresses should be:
> 
>        Routing prefix|Site|IID
>                      |topo|
> host1: 2002:xxyy:zz01:0001:HST1:I:I:D/64
> host2: 2002:xxyy:zz01:0001:HST2:I:I:D/64
>                      |    |
> 
> 
> However, if there is a 6to4 interface enabled on the hosts, 
> it breaks thinks as the hosts might decide to use:
> 
>        Routing prefix|Site|IID
>                      |topo|
> host1: 2002:xxyy:zz66:????:HST1:I:I:D/64
> host2: 2002:xxyy:zz67:????:HST2:I:I:D/64
>                    ^^|    |
>                    ||
>                    ??
> 
> Not only this is not what I want but it does break things as 
> these two hosts are not even in the same IPv6 logical subnet 
> with the 6to4 address they pick. If these two hosts need to 
> talk together they need to transit by the router, no good.
> 
> In other words: the fact that the RFC does not mention that 
> hosts must not have a 6to4 pseudo-interface enabled if the 
> link has a native prefix including those within 2002::/16 
> does not change the reality that 6to4 interfaces on hosts 
> break things so using them is not an option unless there is 
> only one host per site.

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