On 20 July 2011 16:57, Rémi Després <[email protected]> wrote: > > Le 20 juil. 2011 à 16:20, Wojciech Dec a écrit : > >>> ... >>> Sec 5.5 indeed says "A 4V6 CE will have a "self configured" 4V6 IPv6 >>> interface address, alongside any other SLAAC or DHCPv6 derived addresses, >>> potentially from the same prefix." >>> But it remains that the "self-configured" 4V6 address looks like a valid >>> SLAAC or DHCPv6 assigned address. >> >> Well, what it is, and what it looks like is *an IPv6 address* and it >> is valid, and it is in the 4V6 prefix, > > That's what I meant: > Although the 4V6 address was obtained neither with SLAAC nor with DHCPv6, it > can't be distinguished from an ordinary SLAA-C of DHCPv6-obtained address.
It is an IPv6 address, granted. There is however something special about it, as per the 4rd spec. It has a well known IID, and in effect becomes a kind of well-known address. > >> so I don't quite see what is >> the issue you're making out. Are you perhaps thinking of a prefix as >> being a single address? > > NO (?!) > > >>> In my understanding, the problem is that a receiving CE cannot make the >>> difference: >>> - between a source 4V6 address coming from a 4v6 CE and one coming from a >>> non-4V6 CE >>> - between its CE 4V6 address and a real IPv6 destination starting with the >>> assigned IPv6 prefix >>> With "4V6 Encapsulation", making these differences is unnecessary, but with >>> "4V6 Translation" a safe way to recognize IPv4 packets is AFAIK missing. >> >> As per items 1, 2 and 3 above; the CPE does NOT need to make the >> distinction you make out. > >> If packets are sent to that address, they >> get passed to NAT44. Hosts behind the CPE or apps on the CPE will not >> use/bind to that address. > > AFAIK, this prohibits using the full CE-assigned IPv6 on the CE LAN side. > Such a constraint isn't needed with "4V6 encapsulation". No. A 4v6 prefix can be advertised out of the CE LAN, and an fully formed address (eg SLAAC) from it assigned. In fact, the 4V6 address can be "wherever" on the CPE should you choose to implement it that way - how you do this is subject to CPE implementation. Just as it is implementation specific how you dictate the 4V6 function to source packets from that address, and how you prevent some other CPE based process that wants to use IPv6 from using that 4v6 address (eg another process that also wants to use IPinIP encap, or whatever). Yes, there is a difference when implementing the tunneling and the translation modes on the CPE - that's stating the obvious if you ask me, but point taken, I will remark on this in the draft. -Woj. > > RD > > > > >> Regards, >> Woj. >>> >>> Regards, >>> RD >>> >>> >>>> >>>> >>>> >>>> On 19/07/2011 10:55, "Rémi Després" <[email protected]> wrote: >>>> >>>>> Hi, all, >>>>> >>>>> 1. >>>>> The translation-based stateless solution for IPv4 via IPv6 described in >>>>> draft-murakami-softwire-4v6-translation-00 seems to have a significant >>>>> limitation: >>>>> - When a 4V6T customer-edge node receives a packet from a CE of the same >>>>> 4V6T >>>>> domain, it doesn't know whether it must treat it as a native IPv6 packet >>>>> from >>>>> this CE or as an IPv4 packet that this CE has translated. >>>>> >>>>> >>>>> <-- 4V6T domain --> <-- IPv4 Internet -- >>>>> >>>>> (A) 4V6T CE |---->----. >>>>> | >>>>> V---- 4v6T-BR --- - - - >>>>> | >>>>> (B) 4V6T CE |----<----' >>>>> <= v4 or v6 ?? >>>>> >>>>> For instance, if the IPv4 address of (B) is shared, (B) doesn't know >>>>> whether >>>>> received packets must go to its internal NAT44, or be treated a real IPv6 >>>>> packet. >>>>> (Sending to the NAT44 packets whose ports are currently bound in the NAT44 >>>>> wouldn't be satisfactory: all ports may be used in IPv6). >>>>> >>>>> 2. >>>>> Note that this problem doesn't apply to the encapsulation-based stateless >>>>> solution (4V6E): >>>>> - A 4V6E CE treats a received IPv6 packet as containing an IPv4 packet >>>>> if, and >>>>> only if, its Next header is IP-in-IP, and the encapsulated packet is IPv4. >>>>> There is no ambiguity. >>>>> >>>>> => Unless something is wrong in the above, or a palliative is devised, >>>>> consideration of this should be added to the comparative analysis of 4V6T >>>>> and >>>>> 4V6E solutions (draft-dec-stateless-4v6). >>>>> >>>>> >>>>> Regards, >>>>> RD >>>> >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/softwires >>> > > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
