Subject: Re: Review of draft "Prefix Assignment in DHCPv6"

From: Ole Trøan <[email-masked]>
Date: Thu, 6 Dec 2012 12:20:59 +0100

Sheng,

> Back in Atlanta, in DHC WG meeting, you said you would review the document. Could you give the comments?

I knew that would come back and haunt me. ;)
comments below. also included dhc and 6man

>> Draft:	   Prefix Assignment in DHCPv6
>> Presenter: Sheng Jiang
>> URL:	   http://tools.ietf.org/html/draft-ietf-dhc-host-gen-id-04
>> Slot:	   5 min
> 
>> ** Ole will review the document and maybe bring it up on 6man
> 
> Many thanks and best regards,

in arbitrary order:

- draft-ietf-mif-dhcpv6-route-option also supports prefix discovery using DHCP
- a host wanting a particular address, why can it not use the "hint" option in a vanilla IA_NA?
- a prefix on a link must always be coordinated with the onlink router, so I don't understand the argument
  of why the "L-flag" isn't needed
- we shouldn't create new DHCPv6 options with T1/T2 timers. those should be put in a separate option
- what do you do if the prefix length is different from /64?

in general I think the use case presented is already supported by DHCPv6 address assignment; the client puts
the addresses it desire as hints in the IA_NA option in DHCPv6 requests.

I think the argument given in the draft for operators wanting a DHCPv6-managed network without ND is flawed.
ND is required for router discovery, neighbour discovery etc anyway. and a router on the link must be configured
with the onlink prefix regardless.

while we can clearly make this work, I don't think it is justified to create a duplicate mechanism for prefix discovery.
section 3.2 RFC1958.

cheers,
Ole

---

From: Sander Steffann <[email-masked]>
Date: Thu, 6 Dec 2012 17:02:15 +0100

Hi Ole,

> while we can clearly make this work, I don't think it is justified to create a duplicate mechanism for prefix discovery.

I fully agree. Those are my thought as well. Thank you for writing them down :-)
Sander

---

From: Xiayangsong <[email-masked]>
Date: Mon, 10 Dec 2012 01:38:09 +0000

Hi Ole

Thank you your review. Please see my inline response.

Thanks
Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Tr?an
Sent: Thursday, December 06, 2012 7:21 PM
To: Sheng Jiang
Cc: <[email-masked]> WG; IPv6 List
Subject: Re: [dhcwg] Review of draft "Prefix Assignment in DHCPv6"

Sheng,

in arbitrary order:

- draft-ietf-mif-dhcpv6-route-option also supports prefix discovery using DHCP
Frank=>Our draft is about prefix for a host's address formulation.

- a host wanting a particular address, why can it not use the "hint" option in a vanilla IA_NA?
Frank=>This draft is about prefix which is a part of  address.
- a prefix on a link must always be coordinated with the onlink router, so I don't understand the argument
  of why the "L-flag" isn't needed
Frank=>we can discuss further.

- we shouldn't create new DHCPv6 options with T1/T2 timers. those should be put in a separate option
Frank=>Please give me a link so that I could check the "SHOULDN'T"  rule.

- what do you do if the prefix length is different from /64?
Frank=>We can discuss later.

in general I think the use case presented is already supported by DHCPv6 address assignment; the client puts
the addresses it desire as hints in the IA_NA option in DHCPv6 requests.
Frank=>I would like to highlight that we should give an option a clear definition. 
Wild usage of existing option is a double sword.

I think the argument given in the draft for operators wanting a DHCPv6-managed network without ND is flawed.
ND is required for router discovery, neighbour discovery etc anyway. and a router on the link must be configured
with the onlink prefix regardless.
Frank=>  ND is not mandatory for network deployments. AFASIK, ND is optional, while
DHCPv6 is mandatory for WiMAX network. 

while we can clearly make this work, I don't think it is justified to create a duplicate mechanism for prefix discovery.
section 3.2 RFC1958.
Frank=>I don't believe this is "a duplicate mechanism" for "THE SAME THING". 

cheers,
Ole

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ole Trøan <[email-masked]>
Date: Mon, 10 Dec 2012 11:52:24 +0100

> Frank=>Please give me a link so that I could check the "SHOULDN'T"  rule.

wouldn't go as far as claiming it is a "SHOULD NOT".
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-03#section-4.3

if we were to create new IA options I do think we should fix this though. preferably in rfc3315bis.

cheers,
Ole

---

From: Xiayangsong <[email-masked]>
Date: Mon, 10 Dec 2012 11:37:42 +0000

Hi Ole

I read the texts you pointed to.  I believe
this inconvenience needs more systematical way to fix,
which is beyond the scope of the draft.

Thanks
Frank

-----Original Message-----
From: Ole Trøan [mailto:[email-masked]] 
Sent: Monday, December 10, 2012 6:52 PM
To: Xiayangsong
Cc: Sheng Jiang; <[email-masked]> WG; IPv6 List
Subject: Re: [dhcwg] Review of draft "Prefix Assignment in DHCPv6"

cheers,
Ole

---

From: Ole Trøan <[email-masked]>
Date: Wed, 12 Dec 2012 09:38:34 +0100

Sheng,

>> I think the argument given in the draft for operators wanting a
>> DHCPv6-managed network without ND is flawed.
>> while we can clearly make this work, I don't think it is justified to create a
>> duplicate mechanism for prefix discovery.
>> section 3.2 RFC1958.
> 
> Hi, Ole,
> 
> Assuming all networks are using SLAAC is not right.
> 
> In WiMAX NWG IPv6 spec, Revision 6, see the attachment.
> 
> Stateful (DHCPv6) address configuration is supported.
> Check Sections 5.11.11.4 and 5.11.12.2. 
> 
> Also, BBF document TR-177 supports stateful address configuration using DHCPv6, check Section 4.2.
> 
> I also know a few ISP desire to use DHCPv6 in their networks.

I make no assumption that all networks are using SLAAC for address assignment.

there is no conflict between using ND for prefix assignment and DHCPv6 for address assignment.

cheers,
Ole

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 12 Dec 2012 08:49:21 +0000

>Sent: Wednesday, December 12, 2012 4:39 PM
>To: Sheng Jiang
>Subject: Re: Review of draft "Prefix Assignment in DHCPv6"
>
>Sheng,
>

So, how can you get host generated addresses, like EUI64 address, CGA, or Privacy address? Particular for CGA, host has to get prefix first, then use prefix as part of input to generate host identifier.

Or you are saying in DHCPv6-managed network, you still use ND to assign prefix. I don't think that deployment is good idea.

Cheers,

Sheng

---

From: Ole Trøan <[email-masked]>
Date: Wed, 12 Dec 2012 10:09:43 +0100

Sheng,

> Or you are saying in DHCPv6-managed network, you still use ND to assign prefix. I don't think that deployment is good idea.

that's how the IPv6 protocols are designed. from the beginning. that's how all DHCPv6 managed networks run today.
I don't see the problem?

cheers,
Ole

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 12 Dec 2012 02:16:46 +0000

Hi, Ole,

Best regards,

Sheng

---

From: Xiayangsong <[email-masked]>
Date: Wed, 12 Dec 2012 10:53:24 +0000

Hi Ole

I am a little bit confused what we are talking about.
Our draft is necessary when there is no SLAAC.

Could you elaborate your viewpoints?

Thanks
Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Tr?an
Sent: Wednesday, December 12, 2012 5:10 PM
To: Sheng Jiang
Cc: <[email-masked]> WG; IPv6 List
Subject: Re: [dhcwg] Review of draft "Prefix Assignment in DHCPv6"

Sheng,

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Dec 2012 15:40:09 +0000

But all IPv6 nodes are required to support SLAAC and all
routers are required to generate RAs. What is the meaning
of "no SLAAC"?

Regards
   Brian

On 12/12/2012 10:53, Xiayangsong wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Dec 2012 16:58:43 +0000

> routers are required to generate RAs. What is the meaning

A router advertisement that doesn't offer any prefixes where stateless autoconfiguration is enabled?

---

From: Ole Trøan <[email-masked]>
Date: Wed, 12 Dec 2012 19:48:02 +0100

Hi,

> Could you elaborate your viewpoints?

the PIO option in RA has several functions.

1) with the A-flag on, it is used by SLAAC.
2) with the L-flag on, it is used for onlink determination (prefix discovery).

"when there is no SLAAC" does that mean?
 - there is no RA
 - there is an empty RA (no PIO)
 - the PIO has A-flag off

if I understand your draft correctly, you want a DHCPv6 alternative to the RA PIO option.
generally we try to avoid duplicate mechanisms, so could you please give a use case?

cheers,
Ole

---

From: Tim Chown <[email-masked]>
Date: Wed, 12 Dec 2012 19:04:58 +0000

> generally we try to avoid duplicate mechanisms, so could you please give a use case?

And so we end up back at
http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00
and
http://www.ietf.org/mail-archive/web/dhcwg/current/msg09715.html

Tim

---

From: Ralph Droms <[email-masked]>
Date: Wed, 12 Dec 2012 14:12:14 -0500

> http://www.ietf.org/mail-archive/web/dhcwg/current/msg09715.html

plus ça change, plus c'est la même chose

(English translation: Groundhog Day*)

- Ralph

*http://en.wikipedia.org/wiki/Groundhog_Day_(film)

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 13 Dec 2012 03:41:10 +0000

>generally we try to avoid duplicate mechanisms, so could you please give a

If the current form of our draft misleaded you, we can modify our draft in future version. Our motivation is these two scenarios you stated. 

- there is no RA

Best regards,

Sheng

---

From: Xiayangsong <[email-masked]>
Date: Thu, 13 Dec 2012 00:19:00 +0000

Hi Ole

There is no ND at all, that is, no NA/NS/RA/RS etc.
You can check the document Sheng sent out in previous
emails.  In WiMAX, DHCPv6 is mandatory while ND is optional.
In a word, in some scenarios, DHCPv6 is the only way
to configure IP address. 

By the way, operators are more familiar to DHCP than ND, 
and they get used to DHCP for address management.

You are right that we should avoid duplicate mechanisms
for the SAME scenario.  However, this is different.

Thanks
Frank

-----Original Message-----
From: Ole Trøan [mailto:[email-masked]] 
Sent: Thursday, December 13, 2012 2:48 AM
To: Xiayangsong
Cc: Sheng Jiang; <[email-masked]> WG; IPv6 List
Subject: Re: [dhcwg] Review of draft "Prefix Assignment in DHCPv6"

Hi,

cheers,
Ole

---

From: Xiayangsong <[email-masked]>
Date: Thu, 13 Dec 2012 00:25:05 +0000

Hi Brian

Probably, I am missing something.
which documents say " all IPv6 nodes are required to support SLAAC "?

Just I mentioned in previous email, SLAAC is optional WiMAX deployment.

Thank
Frank

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Wednesday, December 12, 2012 11:40 PM
To: Xiayangsong
Cc: Ole Trøan; Sheng Jiang; <[email-masked]> WG; IPv6 List
Subject: Re: [dhcwg] Review of draft "Prefix Assignment in DHCPv6"

Regards
   Brian

---

From: Ole Trøan <[email-masked]>
Date: Thu, 13 Dec 2012 09:13:45 +0100

> There is no ND at all, that is, no NA/NS/RA/RS etc.

the document you references states that ND is used like for any other IPv6 link.
where do you get the "no ND" from?

as a thought experiment, how would a link without ND function?
how do you do router discovery, and address resolution?

> In a word, in some scenarios, DHCPv6 is the only way

can you give me the reference in the document. as far as I can see it states no such thing.
what it does mention is "prefix management" on the AR. for that you can use IA_PD.

> and they get used to DHCP for address management.

no-one is saying that you cannot use DHCPV6 address management.
that is already supported with todays specifications.

> for the SAME scenario.  However, this is different.

I may be somewhat dense, could someone else try to explain to me what the scenario is?

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Dec 2012 08:30:11 +0000

Frank,

> which documents say " all IPv6 nodes are required to support SLAAC "?

RFC 6434 says this:

5.9.2. IPv6 Stateless Address Autoconfiguration - RFC 4862

   Hosts MUST support IPv6 Stateless Address Autoconfiguration as
   defined in [RFC4862].  Configuration of static address(es) may be
   supported as well.

   Nodes that are routers MUST be able to generate link-local addresses
   as described in [RFC4862].
...
12. Router-Specific Functionality
...
12.2. Neighbor Discovery for IPv6 - RFC 4861

   Sending Router Advertisements and processing Router Solicitations
   MUST be supported.

It seems clear to me that SLAAC and RA are required functionalities.

If you can justify a scenario where RAs do not include PIO, you can
justify your proposal. But you cannot say there is no SLAAC.

> Just I mentioned in previous email, SLAAC is optional WiMAX deployment.

That is another problem.

   Brian

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 13 Dec 2012 19:26:40 +0000

> Just I mentioned in previous email, SLAAC is optional WiMAX deployment.

The attempt to create an access network without RA/RS is nothing new.
Other (e.g., DSL, PON) access network technologies have considered this and determined that the biggest missing piece is route info. Which is the reason behind draft-ietf-mif-dhcpv6-route-option. But on point-to-point links it is possible to assume the next hop, so that route info isn't needed. A solution without RA is simple on point-to-point links.

I believe the existing address and prefix DHCPv6 options are sufficient to support what you seem to be trying to do. Unless the goal is to be able to share a single prefix among multiple WiMAX endpoints? I'm not familiar with prefix sharing across point-to-point connections, so I'm guessing the expectation is one /64 prefix per WiMAX endpoint?
 
In which case, it would appear that a host could request a /64 IA_PD, and then use that prefix for whatever it wanted. The host doesn't have to be a router, or offer the prefix to any other host. It can create any addresses it wants for itself. In the CE Router (RFC 6204) requirements, the "unnumbered" model is already described, where the RA contains no "A" prefix and no IA_NA is offered; so it takes addresses for itself from the IA_PD. Your proposal seems to be exactly this, with the only difference being that the CE router does try to also offer the IA_PD prefix on its LAN. But since there's nothing policing this (the access network has no clue what use the IA_PD is put to), there's nothing to prevent the host from just keeping the entire IA_PD for itself. Why does this not meet your need?

For a WiMAX-defined endpoint using IA_PD would be no more difficult that what you are proposing. In fact, it would be pretty much the same. For the DHCPv6 server it would be simpler, because the server would not need to have different options that function identically (from the server's perspective). The DHCPv6 server truly does not care what use the IA_PD prefix is put to, or whether the requesting DHCPv6 client is really a "requesting router" or just a device who wants a prefix all to itself.
Barbara