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

[Rémi Després <[e-mail]>]

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