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

[GangChen <[e-mail]>]

Hello Congxiao,

Thanks for the discussion.
Please see my reply inline.

2011/10/5, Congxiao Bao <[e-mail]>:
>> > 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 that is depending on a specific algorithm. I don't see such
limitation in 4v6
translation(http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00)

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

Could you kindly help elaborating why this is critical for 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?

First off, I'm not sure per-host traffic control is a common case for
network operations
Secondly, it could be possible to use first 64 bits differentiating
hosts. Please see Max PSID usage in
http://tools.ietf.org/html/draft-despres-softwire-4rd-addmapping-01#page-15

Many thanks

Gang