Re: [Softwires] Thoughts on provisioning and universal CPE

[Ole Troan <[e-mail]>]

Tom,

tl;dr.
but did you see;
http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-05

that I think proposes what you are saying below. 3 separate containers for LW46,MAP-E and MAP-T.

cheers,
Ole


On Oct 18, 2013, at 9:47 , Tom Taylor <[e-mail]> wrote:

> (Long message)
> 
> Nothing seems to be happening to the work on the universal CPE draft and provisioning of the various transition methods since last meeting. I wanted to summarize the situation to get things moving again, and I do that below. However, after spending the last day or two reviewing the various documents and trying to think how to factor the configuration data, I've come to the conclusion that MAP configuration is too idiosyncratic to be "unified" with configuration for Public 4o6, LW4o6, or DS-Lite.
> 
> IMHO the sensible thing is to provide separate provisioning objects for each of these techniques so that, first, the CPE can signal which ones it supports through its entries in the Parameter Request List option, and then DHCP can send back the one AAA says that subscriber should use.
> 
> Here's what I understand from the Softwires, Sunset4, and DHC Working Group Berlin minutes and the odd bit of list discussion since.
> 
> Tom Taylor
> 
> (1) DHCP Provisioning of IPv4 Options
> ====================================
> 
> The conclusion out of Berlin is that the best general solution to provisioning of IPv4 and transition-specific options is to use DHCPv4 over DHCPv6 as documented in draft-ietf-dhc-dhcpv4-over-dhcpv6-01.txt. The authors of draft-ietf-softwire-map-dhcp-05.txt argue that that document is sufficient to meet the needs of MAP, but it is not a general solution and leaves the other techniques uncovered.
> 
> (2) CPE Considerations
> =====================
> 
> Here is an extract from the Softwires Berlin minutes:
> 
> Mark: Unified-CPE vendors don't have to do 5 different things. CPEs just do one thing.
> Suresh: It's not about processing, just DHCP option.
> Mark: We will have different CPEs
> Ian: There'are also people who need unified model
> Simon: Unified-CPE doesn't mean unify everything. compromise will be very ugly
> Suresh: (to Mark)Do you concern that some people won't implement some options?
> Mark: Some will only implement some of the options. fragment of CPE.
> Mark: Problem is that there will be two kinds of CPE, not a unified CPE
> Suresh: I don't see how the IETF can prevent this (implement a subset of options) from happening. Suggestion?
> Mark: We start to diverge when we start talking in "modes"
> Ian: We very carefully picked the word "mode". we can change it if you want.
> Suresh: Not sure Mark's input is actionable
> 
> From this I draw the conclusion that partial implementation will happen and it's probably a good idea to accommodate it.
> 
> 
> (3) 1-1 Mode
> ===========
> 
> 1-1 mode is the same for Public v4ov6, LW4o6, and MAP. There's no need to tie it to any particular technology. The IPv4 address should be an option on its own, as Ted suggested in the meeting.
> 
> Not sure if the last word recorded in the minutes on the MAP-DHCP topic was from Suresh, but it was:
> 
> "lw4over6 to signal it supports ea=0. we don't want multiple DHCP option draft"
> 
> Of course, calling out the IPv4 public address option in a Parameter Request List option provides such a signal.
> 
> (4) Summary of Provisioned Information
> =====================================
> 
> Common to multiple methods
> --------------------------
> 
> Every method requires signalling of the IPv6 tunnel endpoint addresses at the CPE and the BR. It is assumed that this is done as a preliminary step, as illustrated in draft-ietf-softwire-public-4over6-10.txt Figure 2. That document assumes the provisioning of both addresses is done by DHCPv6, if it is done by DHCP at all.
> 
> Note that RFC 6334 provides the AFTR-Name option, which is an FQDN.
> 
> The IPv4 public address is also common to all techniques in 1-1 mode. This would be provisioned by DHCPv4overDHCPv6, per the consensus noted in (1) above.
> 
> 
> Public 4over6
> -------------
> 
> No additional provisioning beyond public IPv4 address.
> 
> DS-Lite (RFC 6333)
> ------------------
> 
> The IPv4 address of an IPv4 DNS server can be passed via DHCPv4overDHCPv6. This would require an update to RFC 6333 section 5.5. The B4 would no longer have to act as a DNS proxy.
> 
> The source IPv4 address used by the B4 needs to be configured if it differs from the default 192.0.0.2. This would most likely be done by static configuration rather than DHCPv4.
> 
> For multicast operation as described in draft-ietf-softwire-dslite-multicast-06.txt, three IPv6 prefixes have to be provisioned: the any-source and source-specific multicast prefixes mPrefix64 and the unicast prefix uPrefix64. Since these values relate specifically to IPv4 to IPv6 transition, they would be provisioned by DHCPv4overDHCPv6.
> 
> Light-Weight 4over6
> -------------------
> 
> An object to specify the assigned port set is required. This would be carried via DHCPv4overDHCPv6.
> 
> MAP-E
> -----
> 
> The MAP CE is provided with one or more mapping rules for the domain in which it participates. That domain is distinguished by an IPv6 MAP BR address, as discussed above. The components of the rule are:
> -- the rule IPv6 prefix and length
> -- the rule IPv4 prefix and length
> -- the length of the EA bit portion of the rule IPv6 prefix.
> 
> Mapping rules would be provided by DHCPv4overDHCPv6, since they relate strictly to transition.
> 
> If multiple mapping rules are provided, mesh mode is implied. If just one mapping rule is provided, the situation is ambiguous, hence an object is required to specify hub-and-spoke versus mesh mode. The 4rd document specifically indicates that mode can vary between domains, so the same assumption is reasonable for MAP-E.
> 
> 4rd
> ---
> 
> 4rd uses similar rules to MAP-E, with the addition of a flag indicating whether well-known ports can be included in the allocated port set.
> 
> 4rd adds tunnel traffic class and domain PMTU as provisionable values.
> 
> The only mandatory addition is domain PMTU. This seems like a fragile way to distinguish 4rd support from MAP-E support. As suggested near the beginning of this note, the sensible approach IMHO is to specify technique-specific DHCPv4 container options so the CPE can indicate which transition techniques it implements by requesting them in the Parameter Request List option.
> 
> Note that 4rd currently assumes DHCPv6 provisioning, but should use DHCPv4overDHCPv6 for most of this information.
> 
> MAP-T
> -----
> 
> Quoting from the MAP-T document, section 6:
> 
>   The MAP-T CE and BR configuration is the same as for MAP-E described
>   in Section 7 of [I-D.ietf-softwire-map] except for two differences:
> 
>   o  Translation mode is used instead of Encapsulation
> 
>   o  Use of the BR's IPv6 prefix instead of address
> 
> Translation mode can be indicated by a MAP-T-specific DHCPv4 container option in line with previous suggestions.
> 
> The BR IPv6 prefix would be provided by DHCPv6, perhaps as the same option that provides BR IPv6 addresses.
> 
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires