Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation

[Satoru Matsushima <[e-mail]>]

On 2011/10/11, at 17:42, Rémi Després wrote:

> 
> Le 11 oct. 2011 à 10:30, Satoru Matsushima a écrit :
> 
>> Leaf, thanks for the summary.
>> 
>> On 2011/10/10, at 20:34, Leaf yeh wrote:
>> 
>>> Remi - >> a1- If the CE has an exclusive or shared IPv4 address:
>>>>> <--------- 64 ------------><8 ><------ L >= 32 -------><48-L><8 >
>>>>> +-------------+--------+---+---+----------------+------+-----+---+
>>>>> | IPv6 prefix |CE index| 0 | V |  IPv4 address  | PSID |  0  | L |
>>>>> +-------------+--------+---+---+----------------+------+-----+---+
>>> Ole - > putting the IPv4 address / port information at the end of the interface identifier will allow for > /64 support. > what's the L?
>>> Remi - Don't see what you found unclear.
>>> 
>>> 
>>> Question: Supposed the question is on the last field, named 'L', in the new address format.
>>> 
>> 
>> Since Remi's draft doesn't specify 'CE IPv6 prefix length', IPv6 prefix can't be self delimiting to extract IPv4 address and port-set ID in the case of double translation. That's my understanding. Is that correct?
> 
> In my understanding, yes.
> 
> Now, putting the "CE IPv6 prefix length" back as a rule parameter shouldn't be a problem if the idea of linking IPv4 and IPv6 sizes of address spaces is abandoned (a choice that, I have to agree, simplifies the design).
> 
> Cheers,
> RD 

I think that it should be exclusive in a domain but it could be coexist in the map specification.

cheers,
--satoru


>> As '4rd-a', and 4via6(draft-murakami-softwire-4v6-translation), the 'L' bits are not necessary because 'CE IPv6 prefix length' is defined through a domain, instead of 'L'.
>> 
>> 
>>> 
>>> Remi - >> A Destination address from a CE to the outside IPv4 Internet is:
>>>>> <--------- 64 ------------>< 8 ><----   32 ----><--- 16 ----><8 >
>>>>> +--------------------------+----+---------------+------------+---+
>>>>> |     BR subnet prefix     | V  |  IPv4 address |      0     |32 |
>>>>> +--------------------------+----+---------------+------------+---+
>>> Ole - this is a big change for encapsulation, where prior to this encapsulation means sending to a single destination.
>>> Remi - Copying an available IPv4 address at a fixed place isn't IMHO a "big change".
>>> 
>>> 
>>> Concern: Supposed the replacement of the 1st 64bits of the BR address with a subnet prefix is not for the tunnel case if the field of IPv4 address can be variable, right?
>> 
>> I think that it could be a case where the BR address with a subnet prefix for the tunnel case. My concern rather than the BR address is that a CE should pick packets up which have 'V' in IID, even destined prefixes are delegated to nodes which are behind of the CE.
>> 
>> 
>>> 
>>> In fact, I doubts we could have the same address mapping for both tunnel and translation. Supposed the address of tunnel end-points is preferred to be fixed, but the address for the translation could be variable.
>>> 
>> 
>> I think we could have it.
>> 
>> cheers,
>> --satoru
>> 
>> 
>>> 
>>> Best Regards,
>>> Leaf
>>> 
>>> 
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Rémi Després
>>> Sent: Thursday, October 06, 2011 6:07 PM
>>> To: Ole Troan
>>> Cc: Softwires-wg
>>> Subject: Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation
>>> 
>>> 
>>> Le 6 oct. 2011 à 18:47, Ole Troan a écrit :
>>> 
>>>> Remi,
>>>> 
>>>> [...]
>>>> 
>>>>> 2.
>>>>> (a)
>>>>> The IPv6 Source address of an IPv4 packet from a CE is:
>>>>> 
>>>>> a1- If the CE has an exclusive or shared IPv4 address:
>>>>> 
>>>>> <--------- 64 ------------><8 ><------ L >= 32 -------><48-L><8 >
>>>>> +-------------+--------+---+---+----------------+------+-----+---+
>>>>> | IPv6 prefix |CE index| 0 | V |  IPv4 address  | PSID |  0  | L |
>>>>> +-------------+--------+---+---+----------------+------+-----+---+
>>>> 
>>>> putting the IPv4 address / port information at the end of the interface identifier will allow for > /64 support.
>>> 
>>> Could you explain more the requirement you have in mind?  
>>> 
>>>> what's the L?
>>> 
>>> On the picture, L is 32 bits + Length(PSID).
>>> Don't see what you found unclear. 
>>> 
>>>> 
>>>> you suggest that the first subnet of an allocation should be used for this purpose.
>>> 
>>> Did I do this?
>>> Please explain because that's not, IMHO,  something to be done.
>>> 
>>>> the first subnet is convenient to use for e.g. manual addressing (since it allows the :: short hand).
>>>> I do wonder if this has to be provisioned. e.g. some deployments may use the first subnet for the link between
>>>> CE and PE. (i.e. a /56 - 1 using the PD exclude option is used).
>>> 
>>> See just above.
>>> 
>>>> 
>>>>> a2- If the CE has an IPv4 prefix:
>>>>> 
>>>>> <--------- 64 ------------><8 ><-- L < 32 --><--- 48-L -----><8 >
>>>>> +-------------+--------+---+---+-------------+---------------+---+
>>>>> | IPv6 prefix |CE index| 0 | V | IPv4 prefix |         0     | L |
>>>>> +-------------+--------+---+---+-------------+---------------+---+
>>>>> 
>>>>> (b)
>>>>> V is the mark that characterizes IPv6 packets that are in reality IPv4 packets.
>>>>> Its value differs from any permitted value of this octet in IPv6 IIDs  (ref RFC 4291).
>>>>> 
>>>>> It is understood that, if double Translation coexists with single translation, concerned ISPs may notify their CEs to use the U octet of RFC 6052 instead of V.
>>>>> 
>>>>> An unambiguous mark is fortunately possible because currently permitted IIDs have in their first octet either bit6 = 0 (the "u" bit"), or bit6 = 1 and bit7= 0 (the "g" bit).
>>>>> With V having "u" = 1 (signifying Universal scope) AND "g" = 1, distinction is therefore deterministic.
>>>>> 
>>>>> The proposed V is = 00000011. 
>>>>> (With other values of this octet, other IID formats can be defined in case some would be useful in the future.)
>>>>> 
>>>>> Note that, if and when a consensus is reached in Softwire, an extension of RFC 4291 will have to be submitted to 6MAN. 
>>>> 
>>>> or rather IEEE?
>>> 
>>> IMHO, IEEE has nothing to do with a marker that is purposely an escape mechanism from the modified EUI-64 format of RFC 4291.
>>> 
>>>> I am not convinced that "V" is needed.
>>> 
>>> The point is more, IMHO, whether you have an objection to it (and in this case which one).
>>> Reason is that we are working for a consensus, and several are satisfied with the explanation that there are use cases where it is useful, and none where it is harmful.
>>> 
>>>> you could even use the IANA OUI if pretty printing was required.
>>> 
>>> The point is that it takes 32 bits which is too much to have IPv4 address + PSID in the IID.
>>> 
>>> 
>>>>> (c)                                   
>>>>> A Destination address from a CE to the outside IPv4 Internet is:
>>>>> <--------- 64 ------------>< 8 ><----   32 ----><--- 16 ----><8 >
>>>>> +--------------------------+----+---------------+------------+---+
>>>>> |     BR subnet prefix     | V  |  IPv4 address |      0     |32 |
>>>>> +--------------------------+----+---------------+------------+---+
>>>> 
>>>> this is a big change for encapsulation, where prior to this encapsulation means sending to a single destination.
>>> 
>>> Copying an available IPv4 address at a fixed place isn't IMHO a "big change".
>>> 
>>>> if we also allow for a BR subnet prefix of /128 I'm OK with this (I think).
>>> 
>>> I don't understand what you mean by "Subnet prefix of /128".
>>> 
>>> 
>>>>> Note that if double-translation CEs are notified to use U instead of V, the last octet becomes 0 per RFC  6052.
>>>> 
>>>> how would a CE know if it was single or double translating?
>>> 
>>> Presumably with a usual method, e.g. DHCPv6.
>>> Anything problematic with that?
>>> 
>>> 
>>>> e.g we could do:
>>>> 
>>>> <--------- 64 ------------><--- 24 ------><----- 32 -------><--8 >
>>>> +-------------+--------+---+--------------------+------+-----+---+
>>>> | IPv6 prefix |CE index| S | 00-00-5E    |  IPv4 address  | PSID |
>>>> +-------------+--------+---+---+----------------+------+-----+---+
>>>> 
>>>> we also need to handle the case where IPv6 prefix + CE index > 64.
>>> 
>>> Please explain more your understanding of this requirement.
>>> (I personally believe we should avoid that.)
>>> 
>>>> I suggest we then just put as much as the interface identifier that will fit.
>>> 
>>> 
>>> May I suggest that, to be more constructive, you could first express your objections to the proposed unified mapping, rather than making a number of new proposals whose justifications are sometimes hard to understand, 
>>> 
>>> Cheers,
>>> RD 
>>> 
>>> 
>>>> 
>>>> cheers,
>>>> Ole
>>>> 
>>>> 
>>> _______________________________________________
>>> Softwires mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/softwires
>>> _______________________________________________
>>> Softwires mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/softwires
>> 
>> 
>