Le 10 nov. 2011 à 19:45, Tina TSOU a écrit : > The version 1 of the draft in section 4 says that Additional mapping rules > are recognized by having a Rule IPv6 prefix different from the base End-user > IPv6 prefix. However after reading section 9 of > tools.ietf.org/html/draft-despres-softwire-4rd-addmapping-01, I understand > that IPv4 Prefix should be different for each prefix. How do we achieve > multiple IPv4 subnets with different Rule IPv6 Prefix?
Not sure about the question, but I look forward to discussing in Taipei? See you there, RD > > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Rémi Després > Sent: Wednesday, November 09, 2011 1:00 AM > To: Tina TSOU > Cc: [email protected] > Subject: Re: [Softwires] MAP Open issues: Back to requirements > > > Le 9 nov. 2011 à 02:24, Tina TSOU a écrit : > >> I am still unclear about this: >> Why do we require multiple mapping rules? > > To permit CE-CE routes to be the same in residual IPv4 as in IPv6 , and to > avoid having full IPv4 addresses in IPv6 prefixes, CEs need to know one > mapping rule per IPv4 prefix. > > Deployments with full IPv4 addresses (the dIVI model) avoid the for multiple > rules, an advantage, but they usually need CE IPv6 prefixes longer than /64, > a limitation that is not acceptable in numerous scenarios. (Also, these > deployments need to import the IPv4 entropy in IPv6 routing, with as many > different IPv6 prefixes to be routed as there are IPv4 prefixes.) > >> 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. > > CE IPv6 prefixes can be delegated independently from IPv4. > Mapping rules can then be defined so that each CE gets: > - its Rule IPv4 prefix (that of the rule whose IPv6 prefix is matched by the > CE IPv6 prefix) > - its EA bits (bits of the CE IPv6 prefix beyond the Rule IPv6 prefix. > > An example is available in sec. 9 of > tools.ietf.org/html/draft-despres-softwire-4rd-addmapping-01. > Hope it helps. > > > Cheers, > RD > > > >> >> >> 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 > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
