> 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.
I guess translation mode may not help you to reveal the secret either. RFC6145 says " Note that the IPv6 addresses in the IPv6 header may not be IPv4- translatable addresses and there will be no corresponding IPv4 addresses representing this IPv6 address. In this case, the translator can do stateful translation. A mechanism by which the translator can instead do stateless translation of this address is left for future work." Stateful translator seems to me a shared IPv4 address might be used for several traversed nodes. b) the TTL security mechanism is still a problem. Please kindly to identify the issue. Gang > 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
