Correcting typo and truncated sentence.
On 20 July 2011 18:02, Wojciech Dec <[email protected]> wrote: > 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 any fully > formed address (eg SLAAC) from it assigned to the CE's LAN or host. > 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
