On 9/29/2011 2:10 AM, Ole Troan wrote:
In this case, CPE should terminate the packet whose IPv6 destination is matched
to CE IPv6 Prefix and then process the decapsulation for 4rd. So, I think this
means that any IPv6 prefix matching to CE IPv6 Prefix can be terminated at 4rd
functionality in CE.
If only talking about encapsulation approach, the CE can check the next header
to see whether the packet is for 4rd (of course, the tunneling by hosts in LAN
may not be allowed in this case).
While, generally to be compatible with double translation, the 4rd IID can be
employed.
That is, after receiving an packet, the CE will check whether the IPv6
destination address matches its delegated prefix, and a 4rd IID exists. if so,
the packet will be processed by 4rd functionality. Otherwise, the packet will
be routed natively to some host attached in LAN.
For this, even though CE IPv6 Prefix can be delegated to the CE, CE can not
delegate any IPv6 prefixes matching to CE IPv6 Prefix to any hosts connected on
the LAN side of the CE. Usually, if the CE can get an IPv6 prefix whose length
is 56bit, CE can delegate an IPv6 prefix having the different prefix length
(i.e. 64bit) to the hosts locating on the LAN side of the CE. But I don't think
it can be working because the IPv6 destination matching to CE IPv6 prefix
(delegated prefix) should be terminated at CPE for 4rd processing. So, in order
to provide Dual-stack for the hosts locating on the LAN side of the CE, an
additional IPv6 prefix different from CE IPv6 Prefix needs to be delegated.
Please see my comments above, the 4rd and IPv6 services can share the same
delegated IPv6 prefix.
I would be tempted to suggest that we write a "an implementation MUST NOT make this
assumption" in the MAP draft.
and that we in IETF documents write this as if there is a prefix reserved for
address mapping.
in the general case there is no way to guarantee that a host doesn't pick the
same IID. and we'll have to specify how this would work with DAD and proxy ND.
I'd rather not. left up to the implementor is my suggestion...
Taking the EUI-64 into account, a careful design of the 4rd IID can make
the probability of conflicts quite low. Then as you mentioned, DAD would
further reduce it.
Anyway, that's not to say I'm in favor of this design, the reason I see,
of doing this is just to accommodate the double translation while not
affect at all the IPv6 addressing (a reserved prefix? no ...).
Cheers,
Jacni
cheers,
Ole
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
