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

[Congxiao Bao <[e-mail]>]

Hi,

2011/10/5 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.
>

If ISP wants to use a single IPv6 prefix for double translation and
Encapsulation, V mark is need.

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

>
>
> > 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.
>
> 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]>:
> >> 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
> >>
> >
>
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>