(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
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
