Subject: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS

From: Simon Perreault <[email-masked]>
Date: Thu, 14 Nov 2013 15:26:52 -0500

WG,

Currently draft-ietf-softwire-map-dhcp-05 says that 
OPTION_S46_IPV4ADDRESS is mandatory. It has to be made at least optional 
so that DHCPv4oDHCPv6 or PCP can be used for IPv4 address provisioning.

Can we go further? Can we just remove OPTION_S46_IPV4ADDRESS? The result 
would be that DHCPv4oDHCPv6 or PCP would become mandatory.

Any opinion on this?

Thanks,
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: Ted Lemon <[email-masked]>
Date: Thu, 14 Nov 2013 20:41:21 +0000

On Nov 14, 2013, at 3:26 PM, Simon Perreault <[email-masked]> wrote:
> Can we go further? Can we just remove OPTION_S46_IPV4ADDRESS? The result would be that DHCPv4oDHCPv6 or PCP would become mandatory.

Doesn't MAP use OPTION_S46_IPV4ADDRESS?

Anyway, I think that having a mechanism for configuring the whole thing with DHCPv6 in the absence of a need for stateful or additional IPv4 configuration is probably good.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 14 Nov 2013 15:49:41 -0500

> Doesn't MAP use OPTION_S46_IPV4ADDRESS?

It does not. Its IPv4 configuration is in OPTION_S46_RULE.

> Anyway, I think that having a mechanism for configuring the whole thing with DHCPv6 in the absence of a need for stateful or additional IPv4 configuration is probably good.

Removing unneeded cruft is probably good too. I mean, if nobody is going 
to use it...

Simon

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Nov 2013 03:53:00 +0000

On Nov 14, 2013, at 3:49 PM, Simon Perreault <[email-masked]> wrote:
> Removing unneeded cruft is probably good too. I mean, if nobody is going to use it...

How sure are you that nobody is going to use it?   Serious question.

---

From: Cong Liu <[email-masked]>
Date: Fri, 15 Nov 2013 14:05:30 +0800

I support change it to "optional".

The "mandatory" here means when using lw4o6_container, OPTION_S46_IPV4ADDRESS
is mandatory => If OPTION_S46_IPV4ADDRESS is not used, do not use
lw4o6_container.
It means when using PCP or DHCPv4oDHCPv6, containers can never be used. So
DHCPv6 can not be used to provision lwAFTR address (OPTION_S46_BR is a
suboption inside containers).

Best Regards,
Cong

2013/11/15 Simon Perreault <[email-masked]>

> OPTION_S46_IPV4ADDRESS is mandatory. It has to be made at least optional so
> that DHCPv4oDHCPv6 or PCP can be used for IPv4 address provisioning.
>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: <[email-masked]>
Date: Fri, 15 Nov 2013 08:37:37 +0100

Hi Simon,

Optional is fine. Removal gives us a hole in the solution.

Currently, we¹ve got lw4o6 deployed as a PoC using a fixed binding between
v6 addr, v4 + ports. As a solution for this particular problem, it works
and provisioning this over DHCPv6 would be much simpler than needing
DHCPv4 over X (which we currently have to use as it¹s the only defined and
implemented lw4o6 provisioning DHCPv4 based mechanism).

Removing OPTION_S46_IPV4ADDRESS effectively means that there needs to be
mandatory support for something else. Adding in DHCPv4overDHCPv6 or PCP
(if you don¹t need it) increases the cruft.

Cheers,
Ian

---

From: Ole Troan <[email-masked]>
Date: Fri, 15 Nov 2013 10:24:33 +0100

Ian,

> (if you don¹t need it) increases the cruft.

if optional, we have to think through the corner cases:
 - how does a CPE know when to initiate DHCPv4 (or PCP)?
 - can a CPE end up with an IPv4 address provisioned both with OPTION_S46_IPV4ADDRESS
   and DHCPv4 (and PCP)?
 - what does the CPE do with IPv4 addresses with longer lifetimes than the softwire?

I'm sure there are more.
keeping choice down makes for a simpler solution.

cheers,
Ole

---

From: <[email-masked]>
Date: Fri, 15 Nov 2013 13:35:02 +0100

Hi Simon,

Thinking further on this topic, I’ve changed my mind…

If you are implementing OPTION_S46_CONT_LW46, I say you have to implement
all of the sub-options necessary to provision it, including
OPTION_S46_IPV4ADDRESS.

If you want to use DHCPV4oDHCPv6 or PCP, then you don’t have to implement
OPTION_S46_XX at all.

Reasoning: 
http://www.ietf.org/mail-archive/web/softwires/current/msg05728.html

Cheers,
Ian

---

From: Qi Sun <[email-masked]>
Date: Fri, 15 Nov 2013 21:10:46 +0800

Ole,

> - how does a CPE know when to initiate DHCPv4 (or PCP)?

[Qi] An enable option (DHCPv6 option) would indicate the CPE to use DHCPv4 (or PCP), like the DHCPv4oDHCPv6 Enable Option in DHCPv4oDHCPv6.

Best Regards,
Qi

---

From: Ole Troan <[email-masked]>
Date: Fri, 15 Nov 2013 14:35:52 +0100

Qi,

> [Qi] An enable option (DHCPv6 option) would indicate the CPE to use DHCPv4 (or PCP), like the DHCPv4oDHCPv6 Enable Option in DHCPv4oDHCPv6.

let me see if I understand your proposal.
provision the softwire with the LW46 container option.

the container options then contains one of:
 - the IPv4 address option
 - enable DHCPv4 option
 - or enable PCP option

?

cheers,
Ole

---

From: Qi Sun <[email-masked]>
Date: Fri, 15 Nov 2013 21:43:46 +0800

Ole

> - the IPv4 address option

I'm thinking of this combination in the container option:
- the BR IPv6 address option
- DHCPv4oDHCPv6 Enable option
- or enable PCP option

Does it make sense?

Best Regards,
Qi

---

From: Cong Liu <[email-masked]>
Date: Fri, 15 Nov 2013 21:49:55 +0800

DHCPv4/PCP enable options will be outside containers, because containers
contains sub-options.

Cong

2013/11/15 Ole Troan <[email-masked]>

> > [Qi] An enable option (DHCPv6 option) would indicate the CPE to use
> DHCPv4 (or PCP), like the DHCPv4oDHCPv6 Enable Option in DHCPv4oDHCPv6.
>

---

From: Simon Perreault <[email-masked]>
Date: Fri, 15 Nov 2013 08:53:12 -0500

>   - how does a CPE know when to initiate DHCPv4 (or PCP)?

I would propose: when OPTION_S46_IPV4ADDRESS is absent.

DHCPv4 or PCP? Whichever one the CPE wants to try, or even both. We 
don't need to signal this.

>   - can a CPE end up with an IPv4 address provisioned both with OPTION_S46_IPV4ADDRESS

Proposal: no. When OPTION_S46_IPV4ADDRESS is present, you shall not do 
DHCPv4. PCP is still OK, since it doesn't technically assign an address 
to the interface, it merely informs the CPE of an existing stateless 
mapping (which may be the same as the one provisioned with 
OPTION_S46_IPV4ADDRESS).

>   - what does the CPE do with IPv4 addresses with longer lifetimes than the softwire?

Shouldn't happen with my proposal above.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Fri, 15 Nov 2013 08:55:13 -0500

> http://www.ietf.org/mail-archive/web/softwires/current/msg05728.html

I'm sorry, I don't understand this at all. Can you explain it like I'm a
two year old?

Simon

---

From: Ole Troan <[email-masked]>
Date: Fri, 15 Nov 2013 14:55:18 +0100

Cong,

> DHCPv4/PCP enable options will be outside containers, because containers contains sub-options.

I don't think that will work.
DHCPv6 server sends two containers MAP_E and LW46.
the client must be able to associate the "enable options" to one of them.
I see Simon is suggesting that we don't need those options anyway, something I concur with.

cheers,
Ole

---

From: Simon Perreault <[email-masked]>
Date: Fri, 15 Nov 2013 08:59:59 -0500

> I see Simon is suggesting that we don't need those options anyway, something I concur with.

Right. I think that the utility of enable options still needs to be 
demonstrated.

Simon

---

From: Ole Troan <[email-masked]>
Date: Fri, 15 Nov 2013 15:01:23 +0100

Simon,

> DHCPv4 or PCP? Whichever one the CPE wants to try, or even both. We don't need to signal this.
> 
> Proposal: no. When OPTION_S46_IPV4ADDRESS is present, you shall not do DHCPv4. PCP is still OK, since it doesn't technically assign an address to the interface, it merely informs the CPE of an existing stateless mapping (which may be the same as the one provisioned with OPTION_S46_IPV4ADDRESS).
> 

yes, I think this makes a lot of sense.
paraphrasing:

- one of the containers are _always_ used to provision the softwire
- the absence of IPv4 address option in the LW46 container triggers DHCPv4
- we can ignore PCP for now

if the client requires other configuration information it can do DHCPv4 as it wish.

the only change required is to make the IPv4 address option in MAP-DHCP optional.
(assuming there isn't consensus to drop it altogether.)

cheers,
Ole

---

From: Simon Perreault <[email-masked]>
Date: Fri, 15 Nov 2013 09:04:05 -0500

> How sure are you that nobody is going to use it?   Serious question.

IMHO, if nobody comes to the WG with a need for it, then we should 
remove it. If anyone comes up with a need for it in the future, it can 
be defined in an extension RFC.

Simon

---

From: Cong Liu <[email-masked]>
Date: Fri, 15 Nov 2013 22:05:43 +0800

Hi Ole,

It's another problem that confused me: do containers contain options or
sub-options.
In map-dhcp-05. Section 4 says they are suboptions, but section 10 requires
DHCPv6 option codes.

Best Regards,
Cong

---

From: Simon Perreault <[email-masked]>
Date: Fri, 15 Nov 2013 09:09:57 -0500

> - we can ignore PCP for now

Nah, PCP is too easy to ignore. :) PCP can always be tried on any 
interface. Doesn't matter if this is LW4o6 or whatever else. PCP is PCP, 
just try it and see if you get anything back.

> if the client requires other configuration information it can do DHCPv4 as it wish.

Right.

If I was implementing a CPE I would unconditionally do DHCPv4oDHCPv6. If 
I have to implement the code anyway, why not always exercise it? Thus my 
question: do we really need OPTION_S46_IPV4ADDRESS? If CPEs do 
DHCPv4oDHCPv6 all the time anyway, we don't really need it.

> (assuming there isn't consensus to drop it altogether.)

Yup.

Simon

---

From: Ole Troan <[email-masked]>
Date: Fri, 15 Nov 2013 15:13:28 +0100

Cong,

> It's another problem that confused me: do containers contain options or sub-options.
> In map-dhcp-05. Section 4 says they are suboptions, but section 10 requires DHCPv6 option codes.

sub-options do come out of the DHCPv6 option name space.
and could be used as first level options in other contexts for that matter.

cheers,
Ole

---

From: Qi Sun <[email-masked]>
Date: Sat, 16 Nov 2013 01:17:05 +0800

Ole,

> - one of the containers are _always_ used to provision the softwire

[Qi] When you say "provisioning the softwire", do you mean convey the v6 address of BR/lwAFTR to the clien?

> - the absence of IPv4 address option in the LW46 container triggers DHCPv4

[Qi] There have been a Enable option for DHCPv4oDHCPv6, I think we can leverage it.

Best Regards,
Qi

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Nov 2013 18:55:17 +0000

On Nov 15, 2013, at 8:59 AM, Simon Perreault <[email-masked]> wrote:
> Right. I think that the utility of enable options still needs to be demonstrated.

Bear in mind that DHCPv4overDHCPv6 is intended to be a broad solution, not a softwires-only solution.   So it makes some sense to have an enable option for it, which should be independent of the softwires DHCP options.

As for PCP, how do you feel about DHCPv4 clients blabbing forever on IPv6-only links?   Now, how about PCP clients on non-PCP links?   No problem?   Why is PCP different?

---

From: Simon Perreault <[email-masked]>
Date: Fri, 15 Nov 2013 14:06:23 -0500

> Bear in mind that DHCPv4overDHCPv6 is intended to be a broad solution, not a softwires-only solution.   So it makes some sense to have an enable option for it, which should be independent of the so…

Right, I had forgotten about that. You're right.

> As for PCP, how do you feel about DHCPv4 clients blabbing forever on IPv6-only links?   Now, how about PCP clients on non-PCP links?   No problem?   Why is PCP different?

Good question, but it needs to be scoped to "PCP requests for IPv4 
external ports". PCP requests for IPv6 external ports still make sense 
in an IPv6-only world.

You're right, it seems to me that we have the same problem with PCP 
requests for IPv4 external ports as we have with DHCPv4. *gasp* I will 
for sure be thinking about this, and how it impacts sunset4.

Thanks,
Simon

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Nov 2013 19:25:44 +0000

On Nov 15, 2013, at 2:06 PM, Simon Perreault <[email-masked]> wrote:
> Good question, but it needs to be scoped to "PCP requests for IPv4 external ports". PCP requests for IPv6 external ports still make sense in an IPv6-only world.

Yes, I think the PCP option actually needs to be a softwires-specific option, and its semantics need to be carefully thought out.

> You're right, it seems to me that we have the same problem with PCP requests for IPv4 external ports as we have with DHCPv4. *gasp* I will for sure be thinking about this, and how it impacts sunset4.

Yup.

---

From: Ole Troan <[email-masked]>
Date: Fri, 15 Nov 2013 23:16:18 +0100

> Bear in mind that DHCPv4overDHCPv6 is intended to be a broad solution, not a softwires-only solution.   So it makes some sense to have an enable option for it, which should be independent of the so…

firstly it would still have to be inside the container.
secondly as Simon pointed out it isn't needed, as the absence of the IPv4 address should suffice.

thirdly we shouldn't be making broad solutions for IPv4.
is there any use case of this outside of softwires?

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Sat, 16 Nov 2013 06:09:38 +0000

> is there any use case of this outside of softwires?

This discussion is not in scope for the softwires working group.   If you want to have this discussion, please raise the issue on the dhcwg mailing list.