Subject: [Softwires] regarding discussion IETF87 tuesday regarding DHCP

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 30 Jul 2013 10:16:14 +0200 (CEST)

Hello.

Just want to be sure a certain use case is covered by the current draft:

I'm an ISP and I don't control CPEs. Customers buy them at local 
electronics store and plug the in. I want to support "all" (or subsetof) 
transition mechanisms for 4 over 6 and 6 over 4 etc. Customers might 
purchase devices that support 0 to all of these mechanisms.

Is there anything in the current discussions about "unified cpe" that 
causes problems in the above scenario? I don't know if I understood 
correctly when I heard stuff about overloading options with slightly 
different meanings in different contexts?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Tue, 30 Jul 2013 12:43:07 +0200

> different meanings in different contexts?

I see three options:

If OPTION_MAP_BIND doesn't exist:

Option 1: Send OPTION_S46_BRULE with EA-length = 0. But you don't get to 
benefit from meshing if you support it.

Option 2: Send *two* OPTION_S46_BRULE, one with EA-length=0, and another 
with EA-length=N. You get to benefit from meshing, but then we need to 
specify how CPEs are to handle multiple BRULEs.

If OPTION_MAP_BIND exists:

Option 3: Send OPTION_S46_BRULE with EA-length=N and OPTION_MAP_BIND.

The current consensus, as I understand it, is for option 3.

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: Mikael Abrahamsson <[email-masked]>
Date: Tue, 30 Jul 2013 13:17:34 +0200 (CEST)

On Tue, 30 Jul 2013, Simon Perreault wrote:

> Option 2: Send *two* OPTION_S46_BRULE, one with EA-length=0, and another with 
> EA-length=N. You get to benefit from meshing, but then we need to specify how 
> CPEs are to handle multiple BRULEs.
>

So, I had some discussion regarding this over lunch, and I now think i 
have some more insight.

So, I have a few problems with the current way this is supposed to be 
implemented. I would like to be able to support multiple transition 
mechanisms using a static dhcp server configuration file. For instance:

If I add option 212 to DHCP server config and the client wants a 6RD 
relay, I give a static answer. If it wants something else, I have a static 
answer for it, tftp server, whatever. If it's not in the config file, I 
have no answer. Completely stateless and static, no logic needed.

I would like to see DHCPv6 work the same way for this, regarding AFTRs. I 
would like to see separate AFTR requests for different types of AFTRs. 
Basically, the AFTR DHCP option should reflect what kind of AFTR is being 
handed out. I don't want to have a single AFTR handle all protocols (not 
in DHCP, not in real life), and I don't want magic depending on certain 
bits in the answer to find out what kind of AFTR should be handed out.

Why can't we have the client ask for lw4over6 if it wants it, and ask for 
MAP-E or MAP-T or whatever it wants, instead of the DHCPv6 server trying 
to figure out through logic what the client might be asking for? Of 
course, people can implement logic if they want to (if client supports 
MAP-E, lw4over6 and $NEWFOO, just give it pw4over6), otherwise just answer 
with all things that is supported in the network. I would probably be good 
if there was some kind of preference figure in there as well with the 
options, so that the ISP can indicate preference to what mechanism should 
be used if there are multiple doing basically the same thing.

This would (I think) address what Ted Lemon was saying that the current 
logic requirements is complicating the DHCPv6 server because it needs to 
have intelligence to figure out what response to give depending on what 
options are being asked for. Now it's possible to give out multiple 
answers at the same time if the client asks for it.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 30 Jul 2013 13:58:23 +0200

Le 2013-07-30 13:17, Mikael Abrahamsson a écrit :
>> Option 1: Send OPTION_S46_BRULE with EA-length = 0. But you don't get
>> to benefit from meshing if you support it.
>>
>> Option 2: Send *two* OPTION_S46_BRULE, one with EA-length=0, and
>> another with EA-length=N. You get to benefit from meshing, but then we
>> need to specify how CPEs are to handle multiple BRULEs.
>>
> relay, I give a static answer. If it wants something else, I have a
> static answer for it, tftp server, whatever. If it's not in the config
> file, I have no answer. Completely stateless and static, no logic needed.
>
> I would like to see DHCPv6 work the same way for this, regarding AFTRs.
> I would like to see separate AFTR requests for different types of AFTRs.
> Basically, the AFTR DHCP option should reflect what kind of AFTR is
> being handed out. I don't want to have a single AFTR handle all
> protocols (not in DHCP, not in real life), and I don't want magic
> depending on certain bits in the answer to find out what kind of AFTR
> should be handed out.
>
> Why can't we have the client ask for lw4over6 if it wants it, and ask
> for MAP-E or MAP-T or whatever it wants, instead of the DHCPv6 server
> trying to figure out through logic what the client might be asking for?
> Of course, people can implement logic if they want to (if client
> supports MAP-E, lw4over6 and $NEWFOO, just give it pw4over6), otherwise
> just answer with all things that is supported in the network. I would
> probably be good if there was some kind of preference figure in there as
> well with the options, so that the ISP can indicate preference to what
> mechanism should be used if there are multiple doing basically the same
> thing.
>

Totally agree. And I believe both options 2 and 3 above fulfill that 
requirement.

Simon

---

From: Qiong <[email-masked]>
Date: Tue, 30 Jul 2013 21:32:59 +0800

Hi Mikael,

Our I-D.sun-softwire-lw4over6-dhcpv6-00 is trying to solve it in this way,
using a separate dhcpv6 option to request the FQDN of lwAFTR. So that the
dhcpv6 server can tell whether it is a lw4over6 client or a ds-lite client.

Best wishes
Qiong

On Tue, Jul 30, 2013 at 7:17 PM, Mikael Abrahamsson <[email-masked]>wrote:

> handed out. I don't want to have a single AFTR handle all protocols (not in
> DHCP, not in real life), and I don't want magic depending on certain bits
> in the answer to find out what kind of AFTR should be handed out.
>
> MAP-E or MAP-T or whatever it wants, instead of the DHCPv6 server trying to
> figure out through logic what the client might be asking for? Of course,
> people can implement logic if they want to (if client supports MAP-E,
> lw4over6 and $NEWFOO, just give it pw4over6), otherwise just answer with
> all things that is supported in the network. I would probably be good if
> there was some kind of preference figure in there as well with the options,
> so that the ISP can indicate preference to what mechanism should be used if
> there are multiple doing basically the same thing.
>
> options are being asked for. Now it's possible to give out multiple answers
> at the same time if the client asks for it.
>
>
> --
> ______________________________**_________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/softwires<https://www.ietf.org/mailman/listinfo/softwires>
>

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 30 Jul 2013 17:09:18 +0200

Hi,

inline...

> specify how CPEs are to handle multiple BRULEs.

Woj> This is strictly speaking not correct, in terms of enabling meshing.
To do that, one would send an FRULE with pretty much the same content as
the BRULE.
Multiple BRULES  really come into the picture with CE's attached to
"multiple domains"

Regards,
Woj.

> DTN made easy, lean, and smart --> http://postellation.viagenie.**ca<http://postellation.viagenie.ca>

---

From: Mark Townsley <[email-masked]>
Date: Tue, 30 Jul 2013 18:05:04 +0200

Mikael,

We discussed this in the hallway a bit, but I'll bring it to the list.

The benefit of the "unified CPE" is not rooted in fewer DHCP options. The real benefit is when there is a single feature for CPE vendors to implement. The more feature fragmentation (our linksys folks called this "splatter"), the less economy of scale, the greater cost, overall, to everyone. With a single "unified" feature, there would be no need to discover whether the CPE was LW46-only, MAP-E-only, or MAP-T-only, or some other combination - It would always be all three, because they would all be part of the same thing. Your DHCP options would then be simple and static, and you would not have to match them up with the type of CPE you had. 

If the features we are talking about were dramatically different from one another, this would of course be a waste of time. They aren't though. From DS-Lite to LW46 to MAP, all are really built up from the same components. One breakdown being:

1. An tunnel encap type and destination: There are only two variants for encap type, "T" or "E". One could imagine more, and this wouldn't be the first tunneling protocol that had multiple ways of getting packets from one end of a tunnel to another. 4rd might be representable as a tunnel-type as well.

2. IPv4+Port to IPv6 binding/mapping: 6rd and "MAP" have what amounts to "tunnel aggregation". As an analogy, think of a single-subscriber tunnel (LW46) as a "hostroute tunnel", and a many-subscriber tunnel as a CIDR prefix for a set of tunnels. What if you had an IP router that could configure a /31 static route, but made you install a separate "hostroute support" feature for a /32? You'd certainly be angry at your vendor ;-)

3. If you include "classic DS-Lite" in the unified feature, the final component is which side of the tunnel the stateful NAPT lives. But, I think that this ship has already sailed. Meaning, we will already be asking CPE to support and maintain two separate 4/6 features. Asking them to support 3 or more is suicide for retail CPE vendors, IPv6 certification, etc. 

If you assume there is truly *one* CPE function, you may have 110% of the code for that vs. any single mode of operation, but you cover 300% of the functionality! From a protocol perspective, the WG is _very_ close to being able to achieve this - and should be commended for it. One final step here and the economies of scale win could be great. 

If we don't take that step, we're not only setting ourselves up for a much bigger fight getting this into CPE gear in a consistent manner across the industry, we are likely wasting our time representing the separate functions in shared DHCP options. 

- Mark

PS: the "tunnel hostroute" works in 6rd as well - if you configure a 6rd CPE in the right way, it works as a point to point IP in IP tunnel to Hurricane Electric. 

On Jul 30, 2013, at 1:17 PM, Mikael Abrahamsson wrote:

>> Option 1: Send OPTION_S46_BRULE with EA-length = 0. But you don't get to benefit from meshing if you support it.
>> 
>> Option 2: Send *two* OPTION_S46_BRULE, one with EA-length=0, and another with EA-length=N. You get to benefit from meshing, but then we need to specify how CPEs are to handle multiple BRULEs.
>> 
> So, I had some discussion regarding this over lunch, and I now think i have some more insight.
> 
> So, I have a few problems with the current way this is supposed to be implemented. I would like to be able to support multiple transition mechanisms using a static dhcp server configuration file. For instance:
> 
> If I add option 212 to DHCP server config and the client wants a 6RD relay, I give a static answer. If it wants something else, I have a static answer for it, tftp server, whatever. If it's not in the config file, I have no answer. Completely stateless and static, no logic needed.
> 
> I would like to see DHCPv6 work the same way for this, regarding AFTRs. I would like to see separate AFTR requests for different types of AFTRs. Basically, the AFTR DHCP option should reflect what kind of AFTR is being handed out. I don't want to have a single AFTR handle all protocols (not in DHCP, not in real life), and I don't want magic depending on certain bits in the answer to find out what kind of AFTR should be handed out.
> 
> Why can't we have the client ask for lw4over6 if it wants it, and ask for MAP-E or MAP-T or whatever it wants, instead of the DHCPv6 server trying to figure out through logic what the client might be asking for? Of course, people can implement logic if they want to (if client supports MAP-E, lw4over6 and $NEWFOO, just give it pw4over6), otherwise just answer with all things that is supported in the network. I would probably be good if there was some kind of preference figure in there as well with the options, so that the ISP can indicate preference to what mechanism should be used if there are multiple doing basically the same thing.
> 
> This would (I think) address what Ted Lemon was saying that the current logic requirements is complicating the DHCPv6 server because it needs to have intelligence to figure out what response to give depending on what options are being asked for. Now it's possible to give out multiple answers at the same time if the client asks for it.
> 
> -- 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires