2012/3/19 Rémi Després <[email protected]> > > Le 2012-03-19 à 06:19, Maoke a écrit : > > Remi, > > please see inline. > > 2012/3/16 Rémi Després <[email protected]> > >> Maoke, >> >> First: >> - My apologies for having not answered this email before receiving a >> reminder (it was by mistake lost in a stack of non-urgent things to do). >> - Thanks for the clear and detailed analysis. >> >> More comments in line. >> >> Le 2012-03-13 à 10:53, Maoke a écrit : >> >> Remi, >> >> discussion on R-16 of Sec 4.7: >> >> > R-16: If a CE or BR receives an ICMPv6 error message [RFC4443], it >> > MUST synthesize an ICMPv4 error packet [RFC0792]. This packet >> > MUST contain the first 8 octets of the discarded-packet IP >> > payload. >> >> now the ICMPv6 error message contains the payload as the "header-mapped" >> IPv6 PDU of the discarded packet. right? so does 4rd-U CE or BR translates >> this ICMPv6 payload to ICMPv4 payload as RFC6145 does? does 4rd-U applies >> the checksum adjustment algorithm between ICMPv6 and ICMPv4 here, as the >> RFC6145 does? (for ICMP, the CNP doesn't help) >> >> if it does, you'd better cite RFC6145 here. if it doesn't, please >> specify. >> >> dear Remi, you didn't respond this. > > > AFAIK, I did, but somewhere else (see ** below). > > > > If the CE or BR has a global IPv4 address, this >> > address MUST be used as source of this packet. Otherwise, the >> > unspecified address 0.0.0.0 SHOULD be used as this source. >> >> let me draw an example for that: >> >> A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 Internet; >> router R2 here)--- B >> >> 1. consider ICMPv6 error happens at R1 >> >> original IPv4 packet at A, sent to B: >> +---------+----------------------------------------------+ >> | IPv4 | payload | >> | hdr, H1 | P1 | >> +---------+----------------------------------------------+ >> >> CE translates (precisely speaking, "header-maps") it to: >> +------------+----------------------------------------------+ >> | IPv6 | payload | >> | header, H2 | P1 | >> +------------+----------------------------------------------+ >> >> R1 found a error for this IPv6 packet, it generates an ICMPv6 report: >> +------------+--------+-----------+-------------------------+ >> | IPv6 | ICMPv6 | IPv6 | payload (truncated to | >> | header, H3 | hdr, C1| header, H2| fit in min IPv6 MTU),P2 | >> +------------+--------+-----------+-------------------------+ >> \_______________ ___________________/ >> V >> as the ICMPv6 error message body >> >> this message feedbacked to CE, who will translate it to: >> +---------+--------+--------+--------------+ >> | IPv4 | ICMPv4 | IPv4 | truncated | >> | hdr, H5 | hdr, C2| hdr, H4| payload, P3 | >> +---------+--------+--------+--------------+ >> |<- 8 octet ->| >> \__________ __________/ >> V >> as the ICMPv4 error message body >> >> it is clear that 4rd-U address mapping is applied for >> >> H1 -> H2 -> H4 >> >> H3 has the source address of R1 while the destination address as the CE. >> >> then, CE's (or BR's for the case of B --> A) global IPv4 address or >> 0.0.0.0 will be used in H5, right? >> >> >> Right. >> >> first of all, the 0.0.0.0 might be a wrong choice. Unspecified Address >> represents either a host not yet having gained an IPv4 address on the LOCAL >> network or an application listening on any addresses of a host. >> >> >> packet with 0.0.0.0 might be dropped by any intermediate routers of >> current implementations. >> >> >> This address never appears on any IPv4 link. >> Intermediate routers being IPv6, there is no problem. >> > > i doubt there is not a use-case where between A and CE there are some > subnet routers. > > >> OK? >> > > 4rd-u isn't concerned with what happens between A and CE. > There, internal hosts have RFC1918 addresses and external hosts public > IPv4 addresses. >
no problem here for 4rd-u, but RFC6145/6146 work also in the case the translator is not located next to the end hosts. then i understand 4rd-u is less flexible. > Anything missing? > > > > ICMPv6 Type = 1 and Code = 0 (Destination unreachable, No >> > route to destination") MUST be translated into ICMPv4 Type = 3 >> > and Code = 0 (Destination unreachable, Net unreachable). >> > ICMPv6 Type = 1 and Code = 0 (Time exceeded, Hop limit >> > exceeded in transit) MUST be translated into ICMPv4 Type = 11 >> > and Code = 0 (Time exceeded, Time to live exceeded in >> > transit). >> >> for C1 -> C2 translation, i have the following comments: >> >> 1) here 4rd-U uses the CE's global IPv4 address >> >> >> (i think "global" refers to a non-shared one, right?) >> >> >> Global address is used as a synonymous of public address. >> If somewhere it seems to mean non-shared address, it must be a mistake. >> >> >> to represent all the error generator inside in the IPv6 domain. this >> surely fits a "tunnel" behavior that attempts to treat the delivery from CE >> to BR as a "link", and therefore the error is responded by the link's end >> point. >> 2) however, if this is treated as a "tunnel", both ICMPv6 hop-limit >> exceeded and ICMPv6 unreachable node should be translated as ICMPv4 >> destination unreachable (Type = 3) host unreachable (Code = 1), because it >> should indicates the link problem of the tunnel. >> 3) translating ICMPv6 Hop Limit Exceeded to ICMPv4 Time Exceeded is a >> typical behavior of path participant rather than a "tunnel". the difference >> of the tunnel and the path participant is: the latter consumes the TTL per >> physical hop. for example, if we set TTL = 32 in H1, tunneling means from A >> to B communication may succeed as long as (A---CE) + (BR---B) doesn't >> exceed 30 hops and CE---BR is well connected; while current 4rd-U means >> from A to B communication may succeed only when total numbers of >> intermediate routers doesn't exceed 31. >> >> this is why typical tunneling solutions initialize the out-header's IPv6 >> Hop Limit to 255. when routing loop happens in the IPv6 domain and Hop >> Limit is consumed out, the link is considered broken. >> >> >> I don't see any problem with having, at tunnel exit, the TTL decreased by >> the number of traversed routers. >> > > you don't see it a problem because you reject the common understanding > about "tunnel" as a virtual link, but define the so-called 4rd-tunnel. it > has been admitted by your statement that "4rd tunnel is not any tunnel". > > > Come on! > This sentence, which isn't in the draft, cannot be understood off context. > > The draft is clear about what a 4rd tunnel is, and the point is that, > hosts *cannot distinguish* between packets that are natively routed e2e, > and those that are tunneled on their way, any number of times and with any > tunnel types. > > > > > my understanding here is "4rd tunnel" is ACTUALLY another path section of > translation, according to its behavior. if you would say "4rd-U is a > translation solution alternative to RFC6145 providing better transparency > in double-translation environment with some cost and uncertain risk", i > would totally accept without any further argument. > > > Both of us know that double translation in general looses some information. > to me, behavior is more important than the acceptable level of information loss. on the other hand, we cannot state 4rd-U doesn't lose any information. > What I wouldn't object to is to rename the Reversible-header-mapping > technique as Reversible-header-translation technique. > Hope you can accept this as sufficient, so that we can keep this work on > real and substantial problems. > real substantial problem includes the need of "tunnel as virtual link" building block in the Internet architecture. > > > 2. consider ICMPv4 error happens at R2: >> >> R2 sees original IPv4 packet at A, sent to B: >> +---------+----------------------------------------------+ >> | IPv4 | payload | >> | hdr, H1 | P1 | >> +---------+----------------------------------------------+ >> >> R2 has found some error with that packet, issuing an ICMPv4 message and >> sending to A: >> +---------+--------+--------+--------------+ >> | IPv4 | ICMPv4 | IPv4 | truncated | >> | hdr, H6 | hdr, C3| hdr, H1| payload, P3 | >> +---------+--------+--------+--------------+ >> |<- 8 octet ->| >> \__________ __________/ >> V >> as the ICMPv4 error message body >> >> 4rd-U BR translates that to IPv6 version (ICMPv4 as payload of IPv6): >> +------------+--------+--------+--------------+ >> | IPv6 | ICMPv4 | IPv4 | truncated | >> | header, H7 | hdr, C3| hdr, H1| payload, P3 | >> +------------+--------+--------+--------------+ >> >> woops, unfortunately, R1 also found something wrong. R1 generates an >> ICMPv6 report, responding back to B: >> +------------+--------+------------+--------+--------+--------------+ >> | IPv6 | ICMPv6 | IPv6 | ICMPv4 | IPv4 | truncated | >> | header, H8 | hdr, C4| header, H7 | hdr, C3| hdr, H1| payload, P3 | >> +------------+--------+------------+--------+--------+--------------+ >> >> BR sees this and makes translation to: >> +---------+--------+---------+--------+--------+------------+ >> | IPv4 | ICMPv4 | IPv4 | ICMPv4 | IPv4 | truncated | >> | hdr, H10| hdr, C5| hdr, H9 | hdr, C3| hdr, H1| payload, P4| >> +---------+--------+---------+--------+--------+------------+ >> |<------- 8 octet ----------->| >> \___________________ __________________/ >> V >> as the ICMPv4 error message body >> >> here an "ICMP of ICMP", which is not allowed in ICMPv4, is generated. >> here 4rd-U can have two options: >> 1) let it be but depends on the IPv4 Internet routers, or host B itself >> to drop the ICMP of ICMP; >> 2) actively check the header in the ICMPv4 message body (H9 above) and >> identify if the protocol of the discard-packet is ICMPv4 too; if so, BR >> drops the packet. >> >> i doubt either is good. anyway, no matter which is used, 4rd-U must deal >> with this issue. (sorry if i missed some text where it has been done.) >> >> > (**) > > The right choice is clearly 2 (RFC792 rightly says: "To avoid the infinite >> regress of messages about messages etc., no ICMP messages are sent about >> ICMP messages.") >> > > > sure 2) is better than 1). however, the remained problem is IPv6 carrying > ICMPv4. i just summarize my concerns here in order the community can judge > the impact: > #1. such kind of packet loses the consistency between the destination > address in the IPv6 header and the source address of original IPv4 header > contained in the ICMP error message. > > > That's getting tricky. > yes. but i don't think people keeping part of original packets in ICMP message body is trivial. > Will you be in Paris so that we can discuss with a piece of paper details > of what you have in mind? (In the following 3 days, I will be busy > otherwise, and will have little or no access to email.) > > sorry but i couldn't go to Paris due to the company's arrangement. > #2. such kind of packet loses IP header integrity mechanism as neither > IPv4's header checksum nor the ICMPv6's checksum containing pseudo-header > is included. > > > Packets discussed here will never be delivered anyway (ICMP about ICMP). > I don't see how any practical concern would appear here. > #2 is not about ICMP about ICMP but about no checksum for IP addresses in IP neither in ICMP. i don't think people keeping checksum here or there is trivial. > > because it is stated that 4rd-U is "ensuring compatibility with IPv6-only > middle boxes that perform deep-packet-inspection", i here point out at > least #1 checking on ICMP error message being sent to the exact source of > original packet, and #2 checking on IP header integrity by calculating the > checksum in header or pseudo-header cannot rely on the functionality of the > middle boxes in the IPv6-only domain that perform deep-packet-inspection. > then 4rd-U CE/BR MUST consider these issues as well. > > (neither MAP-T nor MAP-E has the similar concern). > > > For MAP-E, of course (compatibility with IPv6-only middle boxes is off > scope). > For MAP-T, see above. > IPv6 carrying ICMPv6 is able to be deeply inspected by any IPv6 nodes. no further concern. - maoke > > > > - maoke > > > (**) > > It can be made more explicit in the specification. >> > > In R-16, after "If a CE or BR receives an ICMPv6 error message [RFC4443], > it MUST synthesize an ICMPv4 error packet [RFC0792]" we could add "(unless > the message concerns a ICMP message, as required by [RFC0792] to avoid ICMP > about ICMP)". > > Thanks, > RD > > > > > Thanks. >> > >> >> Cheers, >> RD >> >> >> >> >> >> cheers, >> maoke >> >> 2012/3/12 Rémi Després <[email protected]> >> >>> Hello, all, >>> >>> An updated version of draft-despres-softwire-4rd-u is now available at >>> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05 >>> >>> Differences with -04 include: >>> - DHCPv6 options are now specified >>> - various errors and typos are corrected >>> - some clarifications are added, following received questions and >>> comments >>> - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs >>> and within CPEs) >>> - An editor's note has been added, following a WG-ML discussion, about >>> an additional Mapping-rule parameter that might be needed to assign >>> privileged ports to to some shared-address CEs. >>> - Document layout has been adjusted as a result of other modifications. >>> - the authors list has been completed. >>> >>> Questions and comments are most welcome. >>> >>> Regards, >>> RD >>> >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/softwires >>> >> >> >> > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
