Sent from my iPad
On Feb 3, 2012, at 11:40 PM, "Rémi Després" <[email protected]> wrote: > > Le 2012-02-03 à 18:45, Ole Trøan a écrit : > >> Remi, >> >>>> I might have misunderstood R-11 and R-24. it depends on the V octet. >>>> but I suppose for any solution it is more of a deployment choice than a >>>> inherent limitation to the mechanism. >>> >>> Unless use cases showing a practical limitation of 4rd-U in this respect, >>> this line can then be left out. >>> OK? >> >> yes, to finish off this topic, what happens with 4rd-U if the End-user IPv6 >> prefix is e.g a /96? >> and the V-bits are not adhered to? > > If the End-user doesn't support 4rd-U, nothing to be said. > If 4rd-U is enabled, any prefix longer than /64 that matches a Mapping rule > MUST have the V octet. > > If any you have a case where this isn't sufficient, I will look at it. > >> >> [...] >> >>>>>> | T-mode: Checksum | L4 rewrite | CNP | >>>>> >>>>> (3) The functional point is guaranteeing IPv4-payload preservation, with >>>>> compatibility with ALL protocols using TCP-like checksum, present of >>>>> future, with checksums anywhere in the payload. >>>> >>>> the MDT recommends L4 rewrite: >>>> - this is what existing implementations do >>> >>>> - works for any L4 protocol >>> >>> Present or future without change? >> >> "without change and MAP", isn't that an oxymoron? >> any A+P solution requires support for L4 protocols to extract ports. >> L4 checksum rewrite, as well as port extraction will have to be supported >> for all new L4 protocols. >> the L4 checksum rewrite approach can work with any checksum algorithm. >> that said, do we really think NAT44s will be upgraded to support any new L4? > > Imagine a variant of the SCTP of RFC4960 is introduced where the TCP-like > checksum MAY be used to facilitate its deployment, say SCTP-bis (not a bad > idea IMHO, but here just a hypothesis to answer your point). > => 4rd-H would be compatible with it without any evolution; RFC6145 would > need an upgrade to support it. > > Upgrading NAT44s to support this SCTP-bis would be trivial (ports as the same > place as usual can be mapped as usual. > > >> >> [...] >> >>>>>> | Interface-id | RFC6052 | V octet | >>>>>> | MAP traffic identified by | Address/prefix | Interception of | >>>>>> | | | V octet | >>>>> >>>>> (5) The main functional point of the V octet is to avoid interfering with >>>>> subnet assignments in customer sites. >>>> >>>> the MDT recommendation is to set aside a prefix or an IPv6 address to >>>> terminate MAP traffic. >>> >>> Indeed, so that an IPv6 site to which MAP support is added may have to >>> change its intra-site subnet assignments for this. >>> This is avoided with the V octet. >> >> in the MAP case where there is a single address as tunnel endpoint. that >> address can be taken out of a /64 used also by native. if that /64 exists on >> a link that the MAP CE router is not connected, the prefixes would have to >> be renumbered. > > Right. > Renumbering avoidance being a positive feature, the V octet is useful in this > case. > > In the case of prefixes shorter than /64, all addresses based on the subnet > prefix that happens to be needed to introduce MAP would need to be > renumbered. This is avoided with the V octet of 4rd-U. > > Agreed? > > >> >>>>> (6) Not sure to understand what you mean by "Interception of V octet". >>>>> IPv6 routing within CEs or BRs is sufficient to orient IPv6 packets to >>>>> the 4rd function. >>>> >>>> if classification of MAP packets versus native packets have to be done, >>>> not using the best matching prefix algorithm, but a non contiguous mask. >>>> e.g.: >>>> >>>> a match on: >>>> 2001:db8:1234:*:0V00:* >>> >>> (6.a) In BRs or CEs, the first * isn't needed because its value is fixed so >>> that best matching works. >>> (6.b) In middle boxes, if this is what you discuss, testing the V octet is >>> sufficient. >>> (6.c) Note that use cases where middle boxes interpret tunnel packets is >>> the case where MAP-T and 4rd-H have their functional advantages over MAP-E >>> and 4rd-E. >> >> I know we've discussed the V octet a lot earlier. I can't remember all the >> nuances we discussed. could you summarize, e.g. in the feature draft I >> suggested earlier. > > Please see above. > Also, the 4rd-U draft says: > "The V octet is a 4rd-specific mark. Its function is to ensure that 4rd does > not interfere with the choice of subnet prefixes in CE sites. It can also > facilitate maintenance by facilitating distinction between 4rd Tunnel packets > and native-IPv6 packets. Within CEs, IPv6 packets can safely be routed to > the 4rd function based on a /80 prefix because no internal route for native > IPv6 can have a destination prefix that start with this one." Assume there is a CE Router with /32 IPv6 addresses in an enterprise network. "based on a /80 prefix" for what? Would u elaborate or reword the last sentence for better understanding for readers like me? Merci. > > >> my main concern, is if this would add a new check to the IPv6 forwarding >> path, forever. > > Not understood. > >> >>>>>> | Port mapping algorithm | GMA. Prog. | GMA. Fixed | >>>>> >>>>> (7) Substantial complexity added for GMA isn't justified, in my >>>>> understanding, by real use cases that would need it. >>>>> This could easily be added to 4rd-U if so decides the WG (a waste IMHO). >>>> >>>> GMA and the 4rd-U algorithm is the same algorithm. with the same bit >>>> representation on the wire. >>> >>> - The 4rd-U algorithm is: "A port of the port set contains the PSID, >>> starting at bit 4. >>> >>> - The MAP algorithm is: >>> "1. The port number (P) of a given PSID (K) is composed of: P = R * M * j + >>> M * K + i >>> Where: >>> * PSID: K = 0 to R - 1 >>> * Port range index: j = (4096 / M) / R to ((65536 / M) / R) - 1, if the >>> port numbers (0 - 4095) are excluded. >>> * Contiguous Port index: i = 0 to M - 1 >>> 2. The PSID (K) of a given port number (P) is determined by: >>> K = (floor(P/M)) % R >>> Where: >>> * % is the modulus operator >>> * floor(arg) is a function that returns the largest integer not greater >>> than arg." >>> >>> - It has to be faced that this isn't the same algorithm. This difference is >>> significant because the simpler the algorithm, the simpler is personnel >>> training, and the simpler if network maintenance. >> >> if you were to give the algorithm to calculate the port ranges and how to >> extract the PSID from a port. I think you would see that you end up with the >> same as above. > > Are you sure you mean what you wrote? > (I can't find how this would make sense: in 4rd-U, extracting the PSID > knowing its length k is just extracting bits 4 to 3 + k). > >> 4rd-U only shows the bit format on the wire, while MAP shows how the port >> ranges can be calculated. >> >>>> the MAP text goes in more detail in explaining how to calculate the port >>>> ranges and so on. >>>> 4rd-U has fixed (a) the offset bits, while MAP has the same default, but >>>> allows it to be configured. >>> >>>> >>>>>> | Fragment forwarding on BR | N | Y | >>>>>> | without reassembly | | | >>>>>> | Shared fragmentation id space | N | Y | >>>>>> | BR rewrite fragmentation | N | Y | >>>> >>>> btw, in 4rd-U did you intend for the BR to rewrite the fragmentation id on >>>> packets to the Internet from the CEs? >>> >>> (6-bis) As explained in the draft, not for packets from ALL CEs. >>> But the 4rd-U draft does propose ID rewrite in BRs for packets from CEs >>> having shared addresses. >>> Reason, explained in the draft, is that if original IDs are kept unchanged >>> for shared-address CEs, reassembly may be broken in destination end points. >>> A discussion of this point, which so far had only been discussed verbally, >>> is of course welcome. >> >> I think this is a good idea. >> but why couldn't the fragmentation rewrite be done on the CEs? e.g. by >> splitting fragmentation ID space, just like port space is split? > > This is an alternative which has pros and cons. > - it statically reduces the number of ID shared-addresss CEs can use, a > drawback. > - it significantly simplifies BRs > > Personally, I think your proposal is overall better, at least as long as very > high sharing ratios are avoided. A warning against such sharing ratios can be > added. > Unless there are objections, a next edition of the unified draft will have it. > >> >>>> instead of making the CE use the fragmented fragmentation (sic!) space >>>> directly? >>> >>> Not understood. >>> >>>>>> | Complete IPv6 address / | Y | N | >>>>>> | prefix | | | >>>>> >>>>> (9) Not sure what you mean by a complete IPv6 prefix. I see no functional >>>>> limitation of 4rd-U with prefix lengths. >>>> >>>> ah, misspelling. MAP describes how to provision a complete IPv4 address or >>>> IPv4 prefix. (not IPv6 of course). >>> >>> - Sec 5.1 says: >>> "As far as mapping rules are concerned, the simplest deployment model is >>> that in which the Domain has only one rule (the Default mapping rule). To >>> assign an IPv4 address to a CE in this model, an IPv6 /112 is assigned to >>> it comprising the BR /64 prefix, the V octet, a null octet, and the IPv4 >>> address." >>> Also, the use case of 5.3 uses full IPv4 addresses. >>> I agree however that the text could make it clearer. >>> >>> - A Mapping rule that has Rule IPv4 prefix = 0 and EA-bits length < 32 >>> assigns an IPv4 prefix. >> >> right, so the function here is just like MAP, so we don't need to discuss >> that further. >> >>> BTW, could you use my e-mail address that works in Softwire, otherwise my >>> responses get lost. >> >> if you set the right From: or Reply-To: fields, the replies go to the >> address you like. > > I know, but when I fail to check that the right address was used, my answers > do reach cc addresses and fail to reach the WG list. I then have to send a > copy from the modified source. CCs addressees then receive the same message > twice. > AFAIK, the Reply-to field is intended for cases where the provided address > differs from the source address. > Anyway, thanks for having sent this e-mail to my mailing-list compatible > address. > > Cheers, > RD > > > >> >> cheers, >> Ole >> > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
