Maoke, Thanks for the thorough analysis of how 4rd deals with the various TTL value.
2012-05-23 10:49, Maoke: > 2012/5/23 GangChen <[email protected]> > > 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. > > open (some) details != reveal (all) secrets. > it is "i don't care if you get to know" or "i am happy to let you know", > rather than "i have to let you know". > > we were talking about that 4rd disables operator's right of protecting their > secret rather than the right of revealing it. revealing the secret, we have a > lot of ways, not necessarily through user's traceroute. > > but you hinted me to find that 4rd's traceroute behavior is really a little > worse than RFC6145. For TTL = 255 and TTL = 1, isn't 4rd now BETTER than RFC6145? (Thanks for your previous remarks that contributed to improve support of these values.) Regarding other values, more comments below. > see the detailed example of path below: > > A - B - CE - D(v6) - F(v6) - G(v6) - BR - I - J > > from A to J: > TTL = 1 => B responds; > 2 => CE responds; > 3 => BR responds (as TTL_1 set at CE); > 4 => F(woops!! D is skipped) responds > 5 => G responds > 6 => BR responds again > 7 => I responds > 8 => J responds This interesting example suggests IMHO to simplify R-22 to avoid permitting multiple behaviors. R-22 would just say "192.70.192.254 MUST be used as source address" instead of "If the CE or BR has a global IPv4 address, this address MUST be used as source of this packet. Otherwise, 192.70.192.254 SHOULD be used as this source". With this, we have: TTL = 1 => B responds 2 => CE responds 3 => BR responds 4 => F responds in v6 CE responds to A, SRC=192.70.192.254 5 => G responds in v6 CE responds to A, SRC=192.70.192.254 6 => BR responds 7 => I responds 8 => J responds Thus, where a 4rd tunnel is traversed, trace route gets: - two responses of the tunnel exit node - between these two, as many responses with SRC=192.70.192.254 as there are intermediate IPv6 routers This is a feature I see no reason to avoid or regret. > well, it would be not so bad if all the community of Internet engineers like > such a cute joke. For at least SOME Internet engineers, this as a feature, not as a joke ;-) . > 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. > > eBGP multihop applies non-1 non-255 values for the hop-limited security of > the sessions. both Cisco and Juniper has this well-known functionality. > iptables can be set with ttl module to restrict only packets with ttl higher > than or less than or equal to a certain value (surely not possible to be 1 or > 255) can be accepted or forwarded. AFAIK, this functionality does work across a 4rd domain. Any real case where this would be a problem? RD > of course, 255 is the most important value and normative to RFC5082 but it is > not the only value in practical use. > > - maoke > > > > > 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
