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