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

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

Le 5 oct. 2011 à 22:45, Qiong a écrit :

> Hi, Remi,
> 
> Thanks for your effort. I think this is a big progress after the Interim meeting, and this unified address format is quite clear now.

Thanks.

> Here, I have two comments after a quick review. And I will get back to you if I have more comments later.
> 
> 1. With regard to destination address format, if I understand correctly, it only covers hub&spoke model with a default "BR subnet prefix". Are you intended to propose another format for mesh one ?

The proposed format does cover mesh domains - ref. draft-despres-softwire-4rd-addmapping-01 sections 5. and 9., in which "BR IPv6 address" should now be replaced by "BR IPv6 prefix" (a /64).
 
One or several BR IPv6 prefixes can be explicitly advertised to CEs as parts of Domain mapping rules, e.g. with DHCPv6. 


> Or just cite the "Source address format" as the destination address in MESH situation. I think it would be better to declare it separately for "H&S" and "MESH". This would be more clearer for readers to understand different situations.

When time comes to specify the unified format in a new draft, I agree that a clarification of how it applies to different topologies will be appropriate.
 
> 2. Still for the destination address format, I suggest to embed PSID as well in the lower 64 bits (as in the following).

<--------- 64 ------------>< 8 ><----   32 ----><--- 16 ----><8 >
+--------------------------+----+---------------+------------+---+
|     BR subnet prefix     | V  |  IPv4 address | PSID |  0  | L |
+--------------------------+----+---------------+------------+---+ 

The reported informal agreement we had in Beijing didn't explicitly cover destination addresses, and I just reported what we said, but this is AFAIK the implicit direction to go to.
Yet, there is a point to be taken into account:
- It concerns use cases where IPv6 prefixes are assigned without any relationship with IPv4 prefixes and where different sharing ratios are implicitly expressed by different IPv6 prefix lengths (they aren't the only use cases, but are the only ones where a flat IPv6 routing plan can be used with differentiated sharing ratios).
- For this, a BR or CE that transmits to a CE destination doesn't know the exact PSID length of this CE. It only knows the maximum possible length of this PSID, but this is enough for the right CE to be reached (ref draft-despres-softwire-4rd-addmapping-01 sec 7.)

Thus, for more generality, the format for a Destination CE would rather be:

<--------- 64 ------------>< 8 ><----   32 ----><--- 16 ----><8 >
+--------------------------+----+---------------+--------+---+---+
|     BR subnet prefix     | V  |  IPv4 address |Max PSID| 0 | L |
+--------------------------+----+---------------+--------+---+---+ 

If the PSID length is known, then the Max PSID is the exact PSID, but this isn't the only case.



> This would make it easier for in-the-middle systems(e.g. BNG) to do prefix mapping without packet decapsulation.

Exactly, that's the point of using IIDs to insert useful information.

> And this is quite similar to the source address format. What do you think of it?

Detailed answer above.

Kind regards,
RD






> Best wishes
> 
> Qiong
>   
> 
> On Tue, Oct 4, 2011 at 12:22 PM, Rémi Després <[e-mail]> wrote:
> 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
>