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

[Jacni Qin <[e-mail]>]

hi,

Inline please,

On 10/5/2011 5:42 PM, Congxiao Bao wrote:
> Hi,
>
> 2011/10/5 Rémi Després <[e-mail] 
> <mailto:[e-mail]>>
>
>     ..
>     >
>     > 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.
>
> If ISP wants to use a single IPv6 prefix for double translation and 
> Encapsulation, V mark is need.
>
>
Sorry, I don't follow your point here. If there is only one host behind 
the CE, why do we enable both encapsulation and translation modes? Or 
you're talking about the case where a prefix is assigned? Even in this 
case, do we really want parts of the hosts to live on translation, while 
the others live on encapsulation?

>
>     > 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.
>
> Besides, if a medium or large size ISP can’t get short enough IPv6 
> prefix (ex. /24), the first 64 bits can not contain the whole IPv4 32 
> bits, which cannot make the double translation successful.
>
>
I guess the figures were not intent to show in detail how could the IPv4 
space be derived, where maybe not the whole 32 bits are needed. Anyway, 
it's true that the original IPv4 address has to be embedded in the 
translated-address if the translation approach is employed.

>
>     > 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.
>
> Agree. Having whole IPv4 address in clear form is very critical for 
> operation, like IPv6 ACL.
>
>
>     > 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.
>
If the ACL control is based on the first 64 bits, then that control may 
apply to encapsulation as well.


Cheers,
Jacni

>     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.
>
> The ISP is not able to achieve per-host traffic control without a 
> standard defining last 64 bits. If the ISP does, why not use IPv4+psid 
> in suffix naturally instead of other new bits definition?
>
> Best,
>
> Congxiao
>
>
>     Hope it clarifies.
>
>
>     Regards,
>     RD
>
>
>     >
>     > Many thanks
>     >
>     >
>     >
>     > Gang
>     >
>     > 2011/10/4, Rémi Després <[e-mail]
>     <mailto:[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] <mailto:[e-mail]>
>     >> https://www.ietf.org/mailman/listinfo/softwires
>     >>
>     >
>
>     _______________________________________________
>     Softwires mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/softwires
>
>
>
>
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires