Tina, > 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.
only a single rule (the basic mapping rule) is used to generate an IPv4 address. section 4 describes how a CE finds its BMR. multiple forwarding rules are needed, one for each of the _other_ IPv4 subnets in the domain, to allow for direct CE to CE traffic within the domain, between CEs having IPv4 addresses from different IPv4 subnets. the alternative, having only a single mapping rule, means that all traffic outside of the IPv4 subnet will have to go through the BR. cheers, Ole >> 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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
