I am still unclear about this: Why do we require multiple mapping rules? How does it support multiple IPv4 subnets. End User IPv6 prefix is generated from the Rule IPv6 Prefix + EA bits. So how does the CE know which Rule to use to generate this.
Thanks, Tina > From: Ole Troan <[email protected]> > Date: November 8, 2011 14:14:36 GMT+01:00 > To: Softwires WG <[email protected]> > Subject: MAP Open issues: Back to requirements > > 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
