Re: [Softwires] MAP Open issues: Back to requirements

[Tina TSOU <[e-mail]>]

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?


Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Rémi Després
Sent: Wednesday, November 09, 2011 1:00 AM
To: Tina TSOU
Cc: [e-mail]
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 <[e-mail]>
>> Date: November 8, 2011 14:14:36 GMT+01:00
>> To: Softwires WG <[e-mail]>
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/softwires