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

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

Remi,

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

MAP is more flexible with regards to not depending on the V octet.

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

my point is that MAP is L4 aware anyway, and has to be modified to support any new transport protocol. since code modifications have to be made, then having a checksum neutral function at the network layer doesn't help much. you still need to change code. L4 rewrite is also more flexible in that it will support _any_ checksum algorithm, and most importantly is already implemented in every node.

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

no, I don't think so, but I can't guarantee that I understand your use case.
as I said previously, I would encourage you to write a draft with the additional features including use cases you'd see made to MAP.

[...]

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

give me the algorithm to calculate the set of port ranges with 4rd-U.
my claim is that it is going to look like the description in MAP.


cheers,
Ole