Le 2012-03-19 à 16:08, Maoke a écrit : > > > 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. > 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.) > > > well. i mean in the case of 4rd-U IPv6 carrying ICMPv4, integrity of IP > addresses has no checksum to protect. because IPv6 header has no checksum and > ICMPv4 checksum doesn't cover pseudo-header at all. - maoke
well, I think the risk of corrupted IPv6 header H1 within the domain can be ignored because L2 checks should be sufficient in this case. Note that, in case of RFC6145 translation, checking validity of IPv6 addresses implies checksum computation of the complete ICMPv6 message, which can be long. Do you know BTW if this is actually done in existing implementations? Since the source of the original IPv4 packet is present in both DST(H2) and SRC(H1), a consistency check can easily be performed for this address. A note about this could be added to the draft. Thanks, RD > > > > 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
