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

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

Hi Gang,

Thanks for your comments.
More below.


Le 5 oct. 2011 à 01:10, GangChen a écrit :

> Hello Remi,
> 
> I'm trying to put some comments for such unified address mapping.
> Regarding the deterministic benefit for double translation, I guess we
> only could use V bits to achieve.

Right.
V is indeed a reliable tool for this.


> There are no necessary to put IPv4 and Port-set ID information in last
> 64 bits.

The CE Pv6 prefix included in the /64 Subnet prefix isn't self delimited, so that the length of the CE index can't be determined in this part of the address. 
Having the length of the A or A+P prefix in the IID completes what is needed to derive the CE port-set.


> If I understand correctly, the encoded IPv4 and Port-set ID could help
> to derive a shared/dedicated IPv4 address or IPv4 subnet from the IPv6
> prefix.

Yes.
Besides, having the IPv4 address (or prefix) in clear form, and with an explicit sharing ratio, facilitates maintenance at essentially no cost. 

> It may help encapsulation in same cases(e.g. IPv4 based traffic
> classification,IPv4 ACL, etc).
> However, the translation case is more preferable doing pure IPv6 based
> control for the sake of simpler operation reasons (e.g. IPv6 ACL).
> It's desirable identifying a customer depending on first 64 bits.

A point is that, although some realistic deployments may ignore what is made available in IIDs (at least at the beginning), some others would take advantage of it.
A standard with a straightforward and unified format is AFAIK better than several variants, at least for documentation, training, maintenance etc.

Note also that even with a single standard, it remains possible to add optional variants if found useful for some deployments.

Hope it clarifies.


Regards,
RD


> 
> Many thanks
> 
> 
> 
> Gang
> 
> 2011/10/4, Rémi Després <[e-mail]>:
>> Hi all,
>> 
>> 1.
>> Here is a unified Address Mapping, for both encapsulation and
>> double-translation approaches, that is PROPOSED for IPv4 residual deployment
>> across IPv6-only routing domains.
>> 
>> It results from an informal meeting among participants having different
>> preferences between double-translation and encapsulation solutions (Xing Li,
>> Congxiao Bao, Wojciech Dec, myself, at the end of the Beijing meeting).
>> 
>> The idea is to have a common format that is good for both types of
>> solutions.
>> In particular:
>> - It enriches Double translation by introducing a deterministic way to
>> distinguish a translated IPv4 packet from a native IPv6 packet.
>> - It enriches Encapsulation by expressing, in clear format within an IPv6
>> address, an IPv4 address, an IPv4 prefix, or an IPv4 address + port-set ID.
>> 
>> 
>> 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 |
>> +-------------+--------+---+---+----------------+------+-----+---+
>> 
>> 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.
>> 
>> (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 |
>> +--------------------------+----+---------------+------------+---+
>> 
>> Note that if double-translation CEs are notified to use U instead of V, the
>> last octet becomes 0 per RFC  6052.
>> 
>> 
>> 3.
>> All comments are most welcome.
>> 
>> Kind regards to all,
>> RD
>> 
>> 
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>> 
>