2012/3/20 Rémi Després <[email protected]> > > Le 2012-03-19 à 15:30, Maoke a écrit : > > > > 2012/3/19 Rémi Després <[email protected]> > >> >> Le 2012-03-19 à 11:38, Maoke a écrit : >> ... >> >> >>>> let me draw an example for that: >>>> >>>> A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 Internet; >>>> router R2 here)--- B >>>> >>>> ... >> >> 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. >> >> >> I don't see the configuration you have in mind. >> >> > > people often insert a router between the home CE and their computers ;-) > sometimes, e.g., because the CE has limited number of ports for connection > or less funtioning. > > > > I still don't see the problem with a NAT44 in the CE. > >
the topic is about 0.0.0.0 as the source address for the ICMPv6-translated ICMPv4 message's IP header. if there is a router between the CE and the host, the packet with 0.0.0.0 will be discarded rather than being forwarded, according to the common definition of the "unspecified address". > > If the CE itself, is behind a transparent CPE, I don't see more what the > problem would be. > > > >> >>> Anything missing? >>> >> ... >> >> 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. >> >> >> Not understood. >> >> > > then let's keep our own point for next face-to-face discussion. > > >> >> >> on the other hand, we cannot state 4rd-U doesn't lose any information. >> >> >> 4rd options aren't supported (like in MAP-T) >> What else do you see as lost e2e? >> >> > > not else end-to-end except the original TTL across the IPv6 cloud. > (therefore i said 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. >> >> >> Keeping it simple, without depending on complex and fussy concepts, >> remains IMHO preferable. >> >> >> 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. >> >> >> If not "trivial" at least quite simple: >> >> +------------+--------+------------+--------------+ >> | IPv6 | ICMPv6 | IPv6 | truncated | >> | header, H2 | hdr, C1| header, H1 | payload, P1 | >> +------------+--------+------------+--------------+ >> || >> \/ >> +---------+--------+--------+--------------+ >> | IPv4 | ICMPv4 | IPv4 | truncated | >> | hdr, H2 | hdr, C1| hdr, H3| payload, P2 | >> +---------+--------+--------+--------------+ >> |<- 8 octet ->| >> SRC of H2 is a constant >> DST of H2 and H3, and SRC of H2, are copied from fields in H1 >> The ICMPv4 checksum is computed from scratch. >> >> > > well, not this case. but the > IPv6Header-ICMPv4Header-ICMPv4MsgBody(containing IPv4 header of original > packet). > > > OK. > In a 4rd-u domain, middle boxes shouldn't discard packets having ICMPv4 > payloads. > There is no doubt AFAIK that they can be configured to let go one more > protocol (ICMPv4 in this instance). > > > > 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. >> >> >> >> Your presence will be missed. Sorry to learn that. >> >> > > thanks! it is pity that i cannot discuss with you face-to-face this time. > > >> >> >> >> #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. >> >> >> Not sure to see the issue. >> When an ICMPv4 error message is synthesized, its ICMP checksum can easily >> be computed, as explained above. >> (Always keeping only 8 octets of the original payload, as >> specified, strictly limits the computation.) >> >> > > not the ICMP data checksum, but about the integrity of IP header. in IPv4, > IP header has checksum; in IPv6, ICMPv6 checksum includes the > pseudo-header. > > > Since the ICMPv4 that is synthesized when an ICMPv6 error message is > received is built from scratch (with 8 octets of IPv4 payload copied, but > with newly computed checksums), I can't see where there could be a problem. > (If you still see one, more details would be needed.) > > Regards, > RD > > > > > regards, > maoke > > >> >> >> >> 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. >> >> >> Sure. >> Now, if an ICMPv6 error packet is returned whose partially returned >> payload is that of an ICMPv4 message, i.e. with an unknown protocol in >> IPv6, this packet can be indifferently discarded or forwarded after DPI >> without any negative effect. >> (If not discarded here, it will be discarded at 4rd tunnel exit.) >> >> >> no further concern. >> >> >> >> Cheers, >> RD >> >> >> >> >> >> - 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
