Gang, Le 2012-03-07 à 08:33, GangChen a écrit :
> 2012/3/6, Rémi Després <[email protected]>: >> >>> 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. > > I guess that meet the definition of so-called "atomic fragment". Yes, AKA single-fragment packet. > It's > better to involve some discussions with 6man 6man needs not being concerned in this particular instance, because the fragment header of single-fragment packets only concerns 4rd-aware nodes (4rd CEs, 4rd BRs, NAT64+s). Note also that the usual rule which says "be strict in what you send and tolerant in what you receive" is sufficient to imply that all hosts should accept IPv6 packets with fragment header having Offset=O and M=0 (without obligation to send any). >>> 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. > > How about the two CPE sharing one IPv4 address in hub&spoke mode? > Are there some risks if CPEs send packages with identical ID in IPv6 > fragmentation header? Section 5.5.1 of 4rd-u-04 makes it impossible. >>> 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. > > I perfer to leave NAT64 out of scope. NAT64 as is remains out of scope. What is in scope is only the possibility to improve IPv4 transparency of NAT64 nodes by using transparent tunneling, instead of double translation, when reached by 4rd CEs (making them NAT64+ nodes). This new capability, introduced in -04, is derived from the 464XLAT proposal. With 464XLAT, IPv4 applications in hosts attached to IPv6-only networks can communicate via NAT64s, but IPv4 transparency has limitations which can be eliminated by upgrading NAT64s to NAT64+ status (a backward compatible evolution). > Such transparency could be achieved by whther to add fragmentation header. > Anyway, let's hear some comments from the group OK Thanks, RD >>> 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 >> > Ok. I missed that. This comment is withdrawed > > BRs > > Gang > > >>> 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
