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. > > > 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. OK? > > > 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. > > 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.") It can be made more explicit in the specification. 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
