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

[Ole Trøan <[e-mail]>]

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?

[...]

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

[...]

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

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

my main concern, is if this would add a new check to the IPv6 forwarding path, forever.

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

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

cheers,
Ole