Hi Maoke, Thank you for this quick reaction.
2012-05-22 03:54, Maoke : > hi Remi and other authors, > > thanks a lot for updating the draft. semantics review will follow and here i > only make an incomprehensive but quick response. please don't hesitate to > point out if i misunderstand. > > i assume that the purpose of 4rd (this 4rd = 4rd-U in the past, conceptually) > is still unchanged as it is titled: making a unified solution of > encapsulation and translation for ipv4 residual deployment in an ipv6 domain. > then i would like to clarify that ... Yes, the goal remains a single standard, one that combines useful features of MAP-T and MAP-E proposals. A complementary explanation in section 7 (Relationship with previous work) can be added to clarify it. Besides, if 4rd is retained by the WG for standard track, the word "unified" in the title can be deleted. (It is only a reference to the historical process that led to the specification, the subject of section 7) > 1. the new draft remains ipv4 header checksum not end-to-end transparent for > ICMP and UDP with zero checksum. (*) Assuming that links of 4rd domains have reliable link-layer corruption detections, and that their routers never forward packets that have been corrupted in memory (two acceptable assumptions AFAIK), IPv4 packets forwarded at domain exit have their checksums completely unchanged, unless required for decreased TTL and/or ECN. > even though the CNP in address could protect the integrity of addresses, the > integrity protection provided by full encapsulation for port number and > payload length is still lost. RFC6145 says "when the translator is configured to forward the packet without a UDP checksum, the fragmented IPv4 UDP packets will be translated". Reason why this is acceptable is AFAIK an assumption similar to (*) above. > (=> can 4rd be called as a unified solution unifying encapsulation?) > > 2. end-to-end transparency for TTL=1 and TTL=255 is now protected but other > values are not. i doubt this is enough, because neither RFC4271 nor RFC5082 > is limited to the case only 1 or 255 is applied for the TTL security > mechanism. in practice, eBGP sessions across 1 hop, 2 hops, or several hops > are possible and the BGP speaker may not be very next to the CE nor to the > BR. we noticed that full encapsulation protect any case of TTL. Yes encapsulation maintains *all* TTLs, but: - When MAP-T was proposed as a possible unique standards, this was considered negligible. - 4rd does much more in this respect than MAP-T. > (=> can 4rd be called as a unified solution unifying encapsulation?) > > but it is good that the first bit of IPv6 Hop Limit is now not misused. > > (btw, a minor point of confusion, if TTL_1 = 1, i suppose the IPv6-to-IPv4 > translator should make TTL=0 in the resulted packet; if TTL_255 = 1, it must > result in TTL=254, right? as the virtual link has been a hop.) In my understanding of MAP-E, TTL decrease isn't more part of the tunnel behavior than in 4rd. Routers remain responsible for their usual TTL processing, which is appropriate AFAIK. > 3. TTL=1 and TTL=255 are treated differently may also confuse traceroute. > e.g.: > > A - B - CE --(IPv6 domain)-- BR - C > > when one do tranceroute at A to C, it will result in: > 1 xxx ms xxx ms xxx ms B > 2 xxx ms xxx ms xxx ms CE > 3 xxx ms xxx ms xxx ms BR > 4 xxx ms xxx ms xxx ms (Somewhere in the IPv6 domain) > 5 xxx ms xxx ms xxx ms (Somewhere else in the IPv6 domain) > . > . > . > N xxx ms xxx ms xxx ms BR (woops, again, is it a routing loop?) > N+1 xxx ms xxx ms xxx ms C (IPv6-domain hops are counted) > > don't you think it is strange? the above behavior is neither encapsulation > nor translation, In the traced route above, IPv4 addresses of intra-domain nodes are all the same (the domain entry IPv4 address, if it exists, or 192.70.192.254 as per R-22). This provides a way to detect that a v4/v6 tunnel has been used, with an indication of the number traversed nodes, IMHO a useful feature. Regards, RD > then can we call it as a "unification"? > > thanks a lot for your attention, > - maoke > > 2012/5/21 <[email protected]> > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Softwires Working Group of the > IETF. > > Title : IPv4 Residual Deployment via IPv6 - a unified > Stateless Solution (4rd) > Author(s) : Remi Despres > Reinaldo Penno > Yiu Lee > Gang Chen > Sheng Jiang > Filename : draft-ietf-softwire-4rd-00.txt > Pages : 40 > Date : 2012-05-16 > > The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment > possible via IPv6 networks without maintaining for this per-customer > states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of > 6rd). To cope with the IPv4 address shortage, customers can be > assigned IPv4 addresses with restricted port sets. In some > scenarios, 4rd-capable customer nodes can exchange packets of their > IPv4-only applications via stateful NAT64s that are upgraded to > support 4rd tunnels (in addition to their IP/ICMP translation of > [RFC6145]). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-softwire-4rd-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-4rd-00.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd/ > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
