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
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
