[Softwires] Thoughts on provisioning and universal CPE

[Tom Taylor <[e-mail]>]

(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.