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

[GangChen <[e-mail]>]

Hello Maoke,

Please see my reply inline.

2011/10/8, Maoke <[e-mail]>:
>> > 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
>>
>>
> i suppose Ole and Congxiao have clarified this point, right? for the double
> translation, full ipv4 address is needed.

As Ole said, "for the outside domain traffic" (Actually, I never argue
that point for that case)
Thereby, it's worth to be clarified whether need encoding whole IPv4
address, as the below table

+----------+-----------------+--------------------+
|          |source address   | destination address|
+----------+-----------------+--------------------+
|  CE-CE   |      N/A        |        N/A         |
+----------+-----------------+--------------------+
|  CE-BR   |      N/A        |        Yes         |
+----------+-----------------+--------------------+


>
>> >> 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.
>>
>>
> what do you mean with the "yes"? do you mean having a short-enough Rule-IPv6
> is a prerequisite for deploying 4rd-pd?
>
> for example, a small ISP has its Rule IPv4 prefix such as 10/8, while its
> total IPv6 block is a /48 or a /56 prefix only. the ISP is deploying
> stateless transition, possibly 4rd-pd. is such an ISP surely able to pad
> necessary part of IPv4 address in the first 64 bits?

I guess I have already put some comments on that. Please see below.

>> >> 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.
>
>
> it *could* be *possible* for *some* ISP but not for any ISP, right?
>
>
>> 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)
>>
>>
> i don't think all current practices are "trying to encode the information in
> the first 64bits". to my humble understanding, at least divi-pd encodes the
> IPv4 full address information, which identifies a specific user, not in the
> first 64 bits.

Thanks for the clarification. That is why you propose to insert full
IPv4 address?


>> >  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.
>>
>>
> in your proposal draft-chen-softwire-4v6-pd-00, you have
>
>   Delegated IPv6 prefix = IPv6 prefix + Add set + Port set
>
> where your Add-set is (32 - IPv4_pref_len) long, right? if the IPv4_pref_len
> = 8 while the IPv6_prefix_len = 48, can your first 64bits identify a user?
>
> thanks and regards,
> maoke
>
>
>> Many thanks
>>
>> Gang
>>
>