[Softwires] MAP Open issues: Back to requirements

[Ole Troan <[e-mail]>]

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

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?

   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.


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.

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

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.

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