Re: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U

[Rémi Després <[e-mail]>]

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." 


> 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
>