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. 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
well, it would be not so bad if all the community of Internet engineers
like such a cute 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. 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
