Hi Gang,
Thanks a lot for for the quick and detailed review.
More comments below.
Le 2012-03-06 à 11:09, GangChen a écrit :
> Hello Remi,
>
> Here are few comments for the draft.
> Generally speaking, I'm not sure always carrying fragmentation header
> in 4rd domain is a good idea.
> Since the receiver always treat that as regular fragments.
> That means it tries to reassembly on the BRs and cause some potential risks.
A receiver that receives a fragment header showing that the packet is compete
(Offset=O, M=0) has no reassembly to perform.
No new risk is therefore introduced.
> Some analysis is in draft-gont-6man-ipv6-atomic-fragments-00.txt
Note that in the 4rd case, the only destinations of Tunnel packets are CEs or
BRs (or also NAT64+ as discussed below).
No conflict can exist with hosts that might have a provisional difficulty with
a received fragment header having Offset=0 and M=0.
> Secondly, -04 added NAT64+ parts.
> If I understood correctly, there are no additional requirements for NAT64
> boxes.
Well, NAT64 boxes remain what they are.
Any host can use BIH to look like an IPv6-only host in the NAT64 although it
has a dual stack.
But the advantage of 4rd tunneling over RFC6145 double translation is better
IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future protocols that may
use the TCP checksum algorithms)
For an ISP to extend this advantage to its stateful NAT64, it need to be 4rd
aware (become a NAT64+).
NAT64+, when its sees that an IPv6 address is a 4rd IPv6 address (with a V
octet instead of a "u" octet), use the 4rd header mapping instead of RFC6145
translation.
> The only change is to add NAT64+ mapping rule into the domain.
> I guess the intention is to let 4rd-u become friendly to NAT64, since
> some operators already deployed it.
It is to extend advantages of full transparency of header mapping to ISPs that
deploy stateful NAT64s.
> IMHO, that seems unnecessary. NAT64 is another standalone system.
> 4rd-U could naturally coexist with NAT64 by taking proper routing planning.
> And, you have a good designing on V bits.
> There should be no additional works requested to make these two sets
> into unified one.
> Besides, I guess NAT64+ mapping rule in some sense would do same thing
> in I-D.ietf-behave-nat64-discovery-heuristic
Only almost the same thing, a MAP64+ mapping rule must be announced ONLY with
NAT64s that are upgraded to be NAT64+s.
> Going into more detailed, I guess there are some editorial suggestions.
> In Table 2:
> I guess the field of IDENTIFICATION is missing
Not understood:
+---------------------+-----------------------------------------+
| IPv4 FIELDS | VALUES SET AT DOMAIN EXIT |
+---------------------+-----------------------------------------+
...
| Identification | IPv4 ID |
...
Table 2
> In R-5, there is term "Domain-IPv6-suffix". I guess it should be "Rule
> IPv6 suffix"
Yes, thanks.
> In R-7, it uses the indicator of k. I guess that is different meaning
> with k in R-5?
Yes
Was supposed to be clear enough, but will replace k by s in R-5, no problem.
> In Table 3, at the eighth column, it should be N-N-Y. Otherwise, it
> would be duplicated with sixth column
Good catch, thanks.
> I might back with more comments after my second review.
> Many thanks
Kind regards,
RD
>
> Gang
>
>
> 2012/3/6, Rémi Després <[email protected]>:
>> Hello all,
>>
>> The new version of the unified 4rd proposal is now available at:
>> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-04
>>
>> A summarized comparison of its features with those of MAP-T and MAP-E is
>> about to be posted in draft-despres-softwire-stateless-analysis-tool-01.
>>
>> All questions and comments are most welcome.
>>
>> Regards,
>> Remi, Reinaldo, Jacni, Yiu
>>
>>
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/softwires
>>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
