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". It's better to involve some discussions with 6man >> 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? >> 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. Such transparency could be achieved by whther to add fragmentation header. Anyway, let's hear some comments from the group >> 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
