Subject: [Softwires] Comments on draft-despres-softwire-4rd-addmapping-00

From: Washam Fan <[email-masked]>
Date: Sat, 20 Aug 2011 16:44:24 +0800

Hi,

I support the seperation of address mapping from tunneled or
translated 4rd mechanisms. I have some comments as below.
1. Is there any reason you changed 4rd BR to 4rd AFTR?
2. Is 4rd IID for differentiate native ipv6 packets and translated
ipv6 packets? In other words, tunneled 4rd don't need that.
3. For the ICMPv4 containing the copy of error packets, i think
BR/AFTR or CPE can do forwarding based on the copy of error packets
unless the copy didn't cover the complete TCP/UDP header. For ICMP
echo request, you should say the ID field should be within the port
set range. All these topics are in section 5.1.
4. why omit ipv6 suffix in figure 1?
5.don't get why you pad 0 to ipv6 suffix in figure 2?
6. in the paragraphy just below figure 2, shoud you replace 64 with X
in the L=min(14, 64 ...? BTW, it seems to me, the PSID to port sets
mapping is different from draft-murakami-softwire-4rd-00.
7. in example a in section 6, how come a mapping rule responding to 2
cpe ipv6 prefix length? cpe will get confused when it did forwarding.

Thanks,
washam

---

From: Rémi Després <[email-masked]>
Date: Sat, 20 Aug 2011 12:38:30 +0200

Washam,

Thank you for the detailed reaction.
More below.

Le 20 août 2011 à 10:44, Washam Fan a écrit :

> translated 4rd mechanisms.

Excellent.

> I have some comments as below.

Natural question indeed.
This is because the scope is larger than just tunneling mechanisms.
Thus, it won't be necessary, in in comparison documents, to play with various acronyms.
CPE and AFTR seem to be the most generic ones.

> ipv6 packets? In other words, tunneled 4rd don't need that.

Tunnel solutions also need that a CPE receiving an IPv6 packet can differentiate  the 4rd packet from any IPv6 packets destined to intra-site hosts.
By having the 4rd specific IID, it is achieved without depending on a specific protocol ID for encapsulation.

> set range. All these topics are in section 5.1.

It was supposed to be implicit by its being "processed as though it would be a CPE port.
It can be made more explicit in a later version.   

> 4. why omit ipv6 suffix in figure 1?

The idea is that the suffix is _after_ the CPE IPv6 suffix, and therefore doesn't need to appear in Fig 1. 

> 5.don't get why you pad 0 to ipv6 suffix in figure 2?

Cases are possible where the previous fields don't reach 64 bits.
An example could be added in a later version.  

> mapping is different from draft-murakami-softwire-4rd-00.

Yes.
This is a consequence of the additional objective of UPnP friendliness.
Xiaohong could probably tell more if you need it.

> cpe ipv6 prefix length? cpe will get confused when it did forwarding.

CPE prefix lengths may be different. (It is the Domain prefix length that is given in the rule.)
This is key to be able to assign port sets of different sizes (including 64K) to different customers (at least when the CPE-cascade option isn't necessary).

Regards,
RD

---

From: Washam Fan <[email-masked]>
Date: Sun, 21 Aug 2011 14:01:51 +0800

Hi Remi,

Please see inline.

> This is key to be able to assign port sets of different sizes (including 64K) to different customers (at least when the CPE-cascade option isn't necessary).

Yes. But my concern was, for example, a CPE has the below mapping
rule, cited from the draft:
   +--------------------+--------------------+-------------------------+
   | Domain IPv4 prefix | Domain IPv6 prefix | AFTR IPv6 subnet (e.g.) |
   +--------------------+--------------------+-------------------------+
   |     192.32../12    |    2001:db0::/28   | 2001:db0:aaaa:aaaa::/64 |
   +--------------------+--------------------+-------------------------+

when the CPE forwards a IPv4 packet whose destincation address is
within 192.32../12, how the CPE know it will use /48 CE prefix or /52
CE prefix? Or the mapping rule implies the CPE should use the same CE
preifx length as its own delegated prefix?

THanks,
washam

---

From: Rémi Després <[email-masked]>
Date: Sun, 21 Aug 2011 10:02:12 +0200

Hi Washam,

Please see below.

> rule, cited from the draft:

Ah, I think I better understand your question now.

The SRC CPE _doesn't need to know_ the length of the DST CPE IPv6 prefix length.
If this DST length is 48, the DST IPv6 /64 can contain port-derived bits that have no effect on the route toward this CPE. (It is reachable at its /48, irrespective of bits beyond the /48). 
The DST CPE simply makes NO USE of these extra bits (except possibly to check  their consistency with the L4 payload).

Does this answer you question?

In any case, I believe that a later version of the draft should contain an explanation of that kind, preferably more detailed.
I will work on that.

Thanks for your question.
RD

---

From: Washam Fan <[email-masked]>
Date: Sun, 21 Aug 2011 19:43:24 +0800

Got it. Thanks Remi.
washam