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

[GangChen <[e-mail]>]

Hello Congxiao, Maoke,

Please see my reply inline.

2011/10/6, Congxiao Bao <[e-mail]>:
> Hi, Gang, Maoke
>
> 2011/10/6 Maoke <[e-mail]>
>
>> hi Gang,
>>
>> trying to understand your point, may i follow your message inline? sorry
>> if
>> my questions are trial/naive.
>>
>>  2011/10/6 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)
>>>
>>>
>> i couldn't understand why we "don't see such limitation in 4v6
>> translation". 4via6 translate the private ipv4 address with 4rd mapping
>> rule
>> while the public ipv4 address with RFC6052 algorithm, right? can the both
>> case work fine if an ISP can only get a fairly long IPv6 prefix, like /40
>> or
>> even longer?
>>
>
> Yes, if ISP has /32 IPv6 address, then how to embed 32 bits IPv4 address and
> PSID in the first 64 bits?
>
4v6 translation doesn’t need to embed whole 32 bits IPv4 address
according to the algorithm. Please take look EA-bits usage in
http://tools.ietf.org/html/draft-murakami-softwire-4rd-01 for more
details


>>>
>>> > 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
>>>
>>
>> i think it is common for, maybe, not any network operators but at least
>> some operators. especially for those running middle-to-small ISP services
>> (like my company), the capability of per-host traffic control is
>> definitely
>> needed. a specific but not rare case is suppressing the pathologically
>> greedy download/upload behavior of bot-net boxes.
>>
>
> Agree.
>
>>
>>  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
>>>
>>
>> sorry but i may not yet understand the mapping algorithm. is the Rule IPv6
>> prefix definitely short enough to take all Max CE in the first 64 bits?

Yes, in padding case.


>> again, what if an ISP can only get a fairly long IPv6 prefix?

Can I interpret your question like how can we configure mapping
parameter if ISP only gets a fairly long IPv6 prefix? Yes. I mean that
could be possible for some ISP. However, I find that is somewhat
contradictory with requirement of prefix delegation deployment. (Note:
there are also some statements for this requirement in
draft-boucadair-softwire-stateless-requirements-00 REQ#1, REQ#4). At
least, I see all current practices are trying to encoding the
information in first 64 bits (e.g.
draft-despres-softwire-4rd-addmapping-01
draft-boucadair-behave-ipv6-portrange-04
draft-murakami-softwire-4rd-00
draft-murakami-softwire-4v6-translation-00
draft-xli-behave-divi-pd-01
draft-chen-softwire-4v6-pd-00)


>  For per-host traffic, the prefix length of ACL should be /128. In this
> case, you have to specify the value of the suffix. So different ISPs in the
> IPv6 data path can implement IPv6 ACL without additional knowledge.

Again. If there is a way to identify each user in first 64 bits, why not use.

Many thanks

Gang