Subject: [dhcwg] Prefix length option for Dhcpv6

From: ravi kumar <[email-masked]>
Date: Tue, 1 Mar 2011 14:44:36 +0530

Since the Dhcpv6 client receives a /128 address from Dhcp server, the length
of prefix would not be known to the client unless there are RA's on link
with prefix advertised. Is this not a limitation in the sense that,
stand-alone dhcpv6 address is not useful ? Consider the case of Dhcpv4,
where client receives subnet mask aong with the address. Is there any
equivalent option in Dhcpv6 for this purpose ? The main concern is that in a
router-less network (which might make sense in a small network), the Dhcpv6
address is of not much use with clients not able to reach each other over
ipv6.

regards

Ravi

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 1 Mar 2011 10:50:12 -0500

Hi Ravi,
  This concern has been raised before and was the base for this draft.

http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00

Thanks
Suresh

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of ravi kumar
Sent: Tuesday, March 01, 2011 1:15 AM
To: DHC WG
Subject: [dhcwg] Prefix length option for Dhcpv6

Since the Dhcpv6 client receives a /128 address from Dhcp server, the length of prefix would not be known to the client unless there are RA's on link with prefix advertised. Is this not a limitation in the sense that, stand-alone dhcpv6 address is not useful ? Consider the case of Dhcpv4, where client receives subnet mask aong with the address. Is there any equivalent option in Dhcpv6 for this purpose ? The main concern is that in a router-less network (which might make sense in a small network), the Dhcpv6 address is of not much use with clients not able to reach each other over ipv6.

regards

Ravi

---

From: [email-masked]
Date: Tue, 01 Mar 2011 18:19:29 +0100 (CET)

> http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00

However, this draft is expired, and is presumably going nowhere.
Meanwhile, people are *still* asking for it. The demand is not going
to disappear.

Personally, I can live with DHCPv6 IA_PD and link-local addresses on
the link between CPE and BRAS, and default gateway supplied by RA. But
I don't have to like it. I would turn off RA completely if I could.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Wed, 2 Mar 2011 07:43:02 +1030

> I don't have to like it. I would turn off RA completely if I could.

How would you express your addressing model choice to the
CPEs if you were able to switched off RAs?

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

---

From: Tomasz Mrugalski <[email-masked]>
Date: Tue, 01 Mar 2011 23:50:15 +0100

> Meanwhile, people are *still* asking for it. The demand is not going
There's another, current draft that deals routing configuration:
http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-00

It has been adopted by MIF WG recently. Hopefully, this attempt will be
more successful. In its current form, it does not solve the problem of
conveying prefix length information along with addresses. Therefore
addresses are still supposed to be configured with /128.

-- 
Tomek Mrugalski

---

From: Mark Smith <[email-masked]>
Date: Mon, 7 Mar 2011 19:11:14 +1030

On Tue, 1 Mar 2011 14:44:36 +0530

> address is of not much use with clients not able to reach each other over

Link locals are intended to be used in that scenario, so there is also
no need to run a DHCPv6 server either.

If you did want to run a DHCPv6 server for stateful addressing, you
would need something to issue RAs to indicate the stateful addressing
choice to the end-nodes (i.e. the M & O bits switched on in an RA), so
announcing a PIO to populate the end-nodes' prefix-list isn't any
additional burden. To prevent these nodes from considering the RA
announcing device a default router, the router lifetime for the RA
would be set to zero.

Regards,
Mark.