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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/softwires
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
