Re: [Softwires] MAP Open issues: Back to requirements

Ole,

Sorry to disapprove the approach below.

The draft resulting from the design team work includes a set of 17 requirements (Appendix B), and 5 open issues (four in Appendix A; one in sec 4.1.3). 
Opinion of the WG SHOULD therefore first be expressed on the draft. (It is the result of a collective heavy work, of you in particular. Its value shouldn't be depreciated.) 

This is all the more important that your rephrasing of open issues below is in several instances far from being adequate. 
Not only is it influenced by your own subjectiveness, which to a reasonable extent is unavoidable, but it also reflects AFAIK an incomplete understanding of several of the issues (see below).

Let's then hope we will get useful reactions on the draft, in particular clarification questions.

When participants who want to participate in decisions have reached a reasonably common understanding of open issues, decisions to be made won't be blind decisions.

Cheers,
RD

Le 8 nov. 2011 à 14:14, Ole Troan a écrit :

> the discussions we have had in the design team and on the softwires mailing list reflect that many of us have different views on what a stateless IPv4 over IPv6 solution should look like. there is an astounding amount of innovation in this space; for every problem found there are solutions offered. no stone has been left unturned.
> 
> we are suffering from feature creep.
> 
> I'm asking the working group members to voice an opinion on these selected requirements, so that we can try to get some features pruned, and build some more consensus on a complete MAP solution before Taipei.
> 
> I would beg the design team members to step back for a day or two, to let the rest of the working group speak up.
> 
> 1) Granularity of port range assignments.
>  Do we need to support different port ranges within a single IPv4 shared address? Within a single IPv4 subnet, or
>  between multiple IPv4 subnets?
> 
>  Trade-off: Differentiated port-range size within a single mapping rule, is solved with the Max PSID solution. Resulting in
>             destination spray (MAP traffic sent across a whole End-user prefix (e.g. /56) instead of single destination address.)

The "destination spray" is ALREADY part of the solution because its scope includes double translation which has it in BRs, and in CEs that are assigned IPv4 prefixes shorter than /32. 
The Max PSID, which brings sharing-ratio flexibility without multiplying mapping rules, doesn't therefore depend on an architectural innovation.

> 2) Provisioning with DHCPv6.
>  Must the MAP DHCPv6 option be the same for all MAP CEs, or can it be different, depending on e.g.
>  which IPv4 subnet is used, which BR should be used and so on?

Deployments where MAP DHCPv6 options aren't "the same for all MAP CEs" MUST be supported. This has been very clear at the interim meeting, and never negated AFAIK later on.
The question is, in deployments where they are the same (which is simpler to support in DHCP servers, and simpler to operate), which features remain available. 

>  Trade-off: If the DHCPv6 option is the same for all MAP CEs and you have a requirement to use different BRs for different IPv4
>             subnets, then the consequence is that each mapping rule needs an BR prefix/address _and_ that the CE must use
>             source address based forwarding to reach the correct BR for the right IPv4 subnet.

What you call "source address forwarding" is done by the address- mapping function itself, without any impact on the router function of the node. It has been part SAM/4rd proposals from the beginning, is by no means complex and, this ios its purpose, permits ISP to get IPv4 prefixes from several providers.

This BR/prefix issue is mentioned in your Appendix A.3, and has AFAIK no relationship with the DHCPv6 option being the same for all or not. 

> 3) Co-existence of native IPv6 and MAP traffic within a /64.
>  Must it be possible to have both native IPv6 nodes _and_ MAP traffic within the same IPv6 prefix?
>  There may be deployments like 3G, that in Release prior to 10, only provides a single /64 to a MAP node.
> 
>  Trade-off: If this requirement is combined with the "Max PSID", then the consequence of this is that a "V" flag (position 71/72)
>             in the modified EUI-64 identifier, or using the IANA OUI and trusting that to be handled correctly by implementations
>             is needed. If a unique /128 can be used for MAP traffic, then this can trivially be supported.

The need for a deterministic distinction between native IPv6 traffic and and IPv4 traffic exists as soon as each CE is provisioned with only one IPv6 delegated prefix (/64 or shorter). This is AFAIK Requirement R-15 of your draft.
The V octet is therefore useful independently from the Max PSID mechanism discussed above.

> 4) Checksum adjustment in IPv6 address.
>  Must a double translation solution generate IPv6 packets with a valid L4 checksum?
>  If so, is there any benefit in adjusting the checksum by tweaking bits in the IPv6 address versus updating the L4 checksum?
> 
>  Trade-off: The consequence of fiddling with the bits in the IPv6 address, is "destination spray".

This is AFAIK misleading.
Checksum neutrality has no relationship with "destination spray".

It is a provision that permits to avoid "tweaking" bits of the IPv4 payload, and more generally avoids involvement in any layer-4 consideration. 
It is part of the header mapping that I recently proposed in the 4rd-U draft. Its value is to unify not only address mapping but also packet formats.

Besides, making an IPv6 address checksum neutral is computationally trivial when the IPv4 address and useful parts of the IPv6 address are known (nor more not less than updating UDP/TCP ports). 

> 5) Interface-identfier.
>  Must it be possible for a device in the middle without the MAP rules, to parse the IPv6 address to identify the encapsulated or
>  translated IPv4 addresses and port sets? Does encoding the IPv4 address and PSID in the interface-identifier simplify
>  operation?
> 
>  Trade-off: IPv4 address, PSID and Length parameter must be encoded (and possibly enforced) in the interface-id.

This point was AFAIK no longer in the list of open issues.
Is there a recent reference explaining it?

> just like for an annual meeting in a public company, you'll get advice from the board (i.e. me the editor (there is no consensus in the design team)) what to vote:
> 
> 1) port-range size granularity is per IPv4 subnet. 
> 2) each MAP CE is provisioned with 'correct' information for it. (DHCPv6 option is the same for all CEs using the same rule, but different
>  within a domain).
> 3) Co-existence is only supported when a /128 is used for terminating MAP traffic. Co-existence is not supported in the case of an
>  IPv4 prefix and translation.
> 4) Checksum adjustments are done in L4 header
> 5) Only the full IPv4 address is encoded in the interface-id.

> cheers,
> Ole
> 
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires