Subject: [Softwires] Thoughts on provisioning and universal CPE

From: Tom Taylor <[email-masked]>
Date: Fri, 18 Oct 2013 03:47:26 -0400

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

---

From: Ole Troan <[email-masked]>
Date: Fri, 18 Oct 2013 11:21:50 +0200

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-masked]> 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
> 
> 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
> =====================
> 
> Mark: Unified-CPE vendors don't have to do 5 different things. CPEs just do one thing.
> 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?
> Suresh: I don't see how the IETF can prevent this (implement a subset of options) from happening. Suggestion?
> 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.
> 
> 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.
> 
> 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
> -------------
> 
> 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:
> 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.
> 
> 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
> -----
> 
> 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-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Oct 2013 12:25:23 -0400

> 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 Reque…

That still sounds like a unified CPE document.

---

From: Simon Perreault <[email-masked]>
Date: Sun, 20 Oct 2013 14:20:23 +0200

Le 2013-10-18 09:47, Tom Taylor a écrit :
> Nothing seems to be happening to the work on the universal CPE draft

For everyone's information: there were *a lot* of private discussions 
between the various draft authors. draft-ietf-softwire-map-dhcp-05 is 
one immediate result. The other result is the start of a common 
understanding about what the unified CPE draft is supposed to cover. I 
anticipate much unblocking in Vancouver.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Cong Liu <[email-masked]>
Date: Tue, 22 Oct 2013 20:42:44 +0800

Dear Tom and all,

I think this discussion is significant.

2013/10/18 Tom Taylor <[email-masked]>

> ==============================**======
>
> 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.
>

[Cong] I agree with this conclusion that DHCPv4 over DHCPv6 shoud be used
as the IPv4 provisioning protocol in IPv6 network.
I think it's clear that DHCPv4 is designed for IPv4 address provisioning,
and DHCPv6 is designed for IPv6 address provisioning. I don't understand
what the benefit is to use DHCPv6 for IPv4 address provisioning.

> ==============================**=======
>
> 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.
>

[Cong] map-dhcp-05 defines a new DHCPv6 option OPTION_S46_BR to provide
BR/lwAFTR address. The draft requires both MAP-E and lw4o6 to use this
option.
If a unified tunnel-end option is needed, OPTION_AFTR_NAME in RFC6334
should be used. If this option is not good enough, we should update it.
If OPTION_S46_BR is not going to cover DS-Lite, it should not include lw4o6
either. Then we should define seperate options for each mechanism.
http://tools.ietf.org/html/draft-sun-softwire-lw4over6-dhcpv6-00 describes
such scenario.

> Light-Weight 4over6

[Cong] I agree and think it's a consensus that the recommended provisioning
mechanism for lw4o6 is DHCPv4 over DHCPv6, not DHCPv6.

Best Regards,
Cong

---

From: Ian Farrer <[email-masked]>
Date: Tue, 22 Oct 2013 16:40:11 +0200

Hi Cong,

Please see inline.

Cheers,
Ian

On 22 Oct 2013, at 14:42, Cong Liu <[email-masked]> wrote:

> [Cong] I agree with this conclusion that DHCPv4 over DHCPv6 shoud be used as the IPv4 provisioning protocol in IPv6 network.
> I think it's clear that DHCPv4 is designed for IPv4 address provisioning, and DHCPv6 is designed for IPv6 address provisioning. I don't understand what the benefit is to use DHCPv6 for IPv4 address provisioning.

[ian] From discussions in the DHC WG meetings in Atlanta/Orlando, I understood that there was general agreement that if ONLY IPv4 address / port set / MAP rules were necessary, for static reserved addresses, then provisioning this over DHCPv6 was acceptable. This is from my memory of the discussions, there was no poll taken. However, the MAP-DHCP draft covers this case. 

But, if dynamic v4 addresses or any other DHCPv4 options were necessary, then DHCPv4 over DHCPv6 would be the way of providing this. The v4-configuration document evaluates approaches against these requirements which is why it reaches the conclusion that it does.

So, I see that both can co-exist. They are solutions to meet different requirements and have their own set of limitations.

> [Cong] map-dhcp-05 defines a new DHCPv6 option OPTION_S46_BR to provide BR/lwAFTR address. The draft requires both MAP-E and lw4o6 to use this option.

[ian] map-dhcp-05 only describes a DHCPv6 option for provisioning MAP/lw4o6. It doesn't make any requirements that clients implement the option. Any provisioning requirements are the other way round (i.e. the softwire mechanism draft has a normative reference to the draft that describes provisioning).

> If a unified tunnel-end option is needed, OPTION_AFTR_NAME in RFC6334 should be used. If this option is not good enough, we should update it.
> If OPTION_S46_BR is not going to cover DS-Lite, it should not include lw4o6 either. Then we should define seperate options for each mechanism.
> http://tools.ietf.org/html/draft-sun-softwire-lw4over6-dhcpv6-00 describes such scenario. 
> 
[ian] I don't see a requirement for a unified tunnel-endpoint. Quite the reverse, in fact. If you have several tunnel endpoints for different tunnelling methods, then you probably need a way of separating them so that you can direct client traffic to the right tunnel concentrator.
We tried re-using OPTION_AFTR_NAME, but this gives you the problem of how to identify RFC6333 tunnel clients from other softwire clients so that you can route their traffic accordingly. An existing DS-Lite client does not support OPTION_S46_BR and any practical solution for new softwire mechanisms must be backwards compatible with existing ds-lite clients.

> [Cong] I agree and think it's a consensus that the recommended provisioning mechanism for lw4o6 is DHCPv4 over DHCPv6, not DHCPv6.
> 
> Best Regards, 
> Cong

---

From: Qi Sun <[email-masked]>
Date: Tue, 22 Oct 2013 23:43:06 +0800

Dear Ian,

Please see inline.

On 2013-10-22, at 下午10:40, Ian Farrer wrote:

> [ian] From discussions in the DHC WG meetings in Atlanta/Orlando, I understood that there was general agreement that if ONLY IPv4 address / port set / MAP rules were necessary, for static reserved addresses, then provisioning this over DHCPv6 was acceptable. This is from my memory of the discussions, there was no poll taken.

[Qi] This should be documented as a statement in the map-dhcp to specify the case where to use DHCPv6 options for IPv4 allocation or not, if map-dhcp intends to be a 'Softwire 46 DHCP Options' document.

> However, the MAP-DHCP draft covers this case. 
> 

[Qi] IMO, what you said falls into Cong's second 'if': lw4o6, map-e, ds-lite are different tunnel mechanisms, so that different DHCPv6 options for signaling of tunnel concentrator's v6 address are necessary. Or the client would be not able to identify which tunnel concentrator it should connect to.

Best Regard,
Qi

---

From: Ole Troan <[email-masked]>
Date: Tue, 22 Oct 2013 18:34:38 +0200

Qi,

> [Qi] This should be documented as a statement in the map-dhcp to specify the case where to use DHCPv6 options for IPv4 allocation or not, if map-dhcp intends to be a 'Softwire 46 DHCP Options' docu…

the main concern of MAP-DHCP is to provision the tunnel, i.e. the link-layer.
stateful DHCPv4 is not a possibility with MAP.
I do agree that we could have a paragraph on "other configuration information".

> [Qi] IMO, what you said falls into Cong's second 'if': lw4o6, map-e, ds-lite are different tunnel mechanisms, so that different DHCPv6 options for signaling of tunnel concentrator's v6 address are…

please read the map-dhcp draft.
there are separate container options for the 3 mechanisms that map-dhcp include.

cheers,
Ole