dear Remi, thanks a lot for your clarification.
only some quick reaction with my personal observations: 1. it is not the time to compare 4rd with MAP-T or with MAP-E separately, but with the MAP-suite. i never think MAP-T is intended to be the *unique* standard in the scope of residual deployment. (maybe it "was" but we'd better discuss things based on current understanding) 2. doing much more != doing better correct. a) the "useful feature" of showing number of traverse nodes has been offered by MAP-suite through translation mode. is it really an add-on to the encapsulation? i don't think so. sometimes provider would like to open the tunnel details to the users sometimes they do like to hide the secret. 4rd traceroute behavior forces operator doing the latter. i don't know if everyone like it. i don't anyway. b) the TTL security mechanism is still a problem. c) i said that traceroute behavior is strange, it doesn't mean there are several IPv6 responders. it means there are BR showed twice. and one think 3 hops can reach the BR but 4 hops cannot reach the host C soon next to the BR. this is the strange thing! 3. regarding the link layer assumption, either MAP-T or MAP-E doesn't need such an assumption. (new assumption is new limitation on usability scope to my understanding). and i have pointed out it is not a correct understanding to think things would be reliable as long as link layer is reliable. for detailed investigation on these above observations, i promise i will update the commetary draft to reflect them. but not very quick as i got my hands hurt by the mouse and keyboard recently. :P anyway i am happy that you make the design not touching the first bit of Hop Limit now. thanks! regards, maoke 2012/5/23 Rémi Després <[email protected]> > 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
