Subject: [v6ops] When an RG should issue a DHCPv6 solicit

From: "Frank Bulk" <[email-masked]>
Date: Mon, 22 Aug 2011 17:49:49 -0500

Should an RF issue a DHCPv6 solicit on its WAN interface only upon having
received an RA message with the RA bits marked "M"?  Or can/should it send
one out regardless?

We have a xPON vendor onsite to do some testing with their equipment in our
production IPv6 network and only one of the five RGs are working.  I suspect
it's because the RG's are waiting for that RA.

Any insight or pointers to RFCs would be appreciated.

Frank

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 22 Aug 2011 19:18:37 -0500

Ah ... the M (and O) bits ... that debate wasted a lot of bits.

I think the summary was (though hopefully this won't start another
debate -- great if someone corrects me if I erred though) is that *if*
the M (or O) bit is set, a device SHOULD do DHCPv6. Whether it does
DHCPv6 without the M or O bit set is up to the device itself (or the
configuration). There is no requirement either way (I guess in RFC
language this might be "a host MAY run DHCPv6").

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Frank Bulk
Sent: Monday, August 22, 2011 6:50 PM
To: 'IPv6 Operations'
Subject: [v6ops] When an RG should issue a DHCPv6 solicit

Should an RF issue a DHCPv6 solicit on its WAN interface only upon
having
received an RA message with the RA bits marked "M"?  Or can/should it
send
one out regardless?

We have a xPON vendor onsite to do some testing with their equipment in
our
production IPv6 network and only one of the five RGs are working.  I
suspect
it's because the RG's are waiting for that RA.

Frank

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

---

From: "Frank Bulk" <[email-masked]>
Date: Mon, 22 Aug 2011 19:40:49 -0500

Thanks, but that doesn't really hit the core of my question.	

I believe TR-124i2 allows for a Router Solicitation and DHCPv6 to occur
simultaneously, while previously the router waited for the RA before
initiating a DHCPv6 Solicit.

The access gear that a vendor is testing in our network appears to be
blocking the RA, and so two of the three CPE I tested so far doesn't get a
default IPv6 gateway and doesn't initiate DHCPv6 to get a prefix for the LAN
interface.  Obviously blocking the RA is an issue. =)

Frank

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Monday, August 22, 2011 7:19 PM
To: [email-masked]; IPv6 Operations
Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit

- Bernie

-----Original Message-----

Frank

---

From: james woodyatt <[email-masked]>
Date: Mon, 22 Aug 2011 17:51:40 -0700

On Aug 22, 2011, at 17:40 , Frank Bulk wrote:
> 
> Obviously blocking the RA is an issue.

Yes, a residential gateway MAY decide not to start the DHCPv6 client if there are no router advertisements to process.  Without any default routers on the WAN link, a DHCPv6 lease from the network won't be very useful to a residential gateway.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 22 Aug 2011 20:22:33 -0500

http://www.broadband-forum.org/technical/download/TR-124_Issue-2.pdf

Section A.2 - the flowchart seems to show both running in parallel which
seems to imply that a TR124 compatible device does not need an RA (with
M/O bits set) to start DHCPv6.

Doing a quick look, I didn't see anything more that detailed the
process.

- Bernie

-----Original Message-----
From: Frank Bulk [mailto:[email-masked]] 
Sent: Monday, August 22, 2011 8:41 PM
To: Bernie Volz (volz); IPv6 Operations
Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit

The access gear that a vendor is testing in our network appears to be
blocking the RA, and so two of the three CPE I tested so far doesn't get
a
default IPv6 gateway and doesn't initiate DHCPv6 to get a prefix for the
LAN
interface.  Obviously blocking the RA is an issue. =)

Frank

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Monday, August 22, 2011 7:19 PM
To: [email-masked]; IPv6 Operations
Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit

- Bernie

-----Original Message-----

Frank

---

From: Ole Troan <[email-masked]>
Date: Tue, 23 Aug 2011 04:04:31 +0200

Frank,

> interface.  Obviously blocking the RA is an issue. =)

the can be done in parallel. the M bit is just a hint and in any case not relevant to prefix delegation.
see RFC6204, WPD-4 among other requirements in the draft.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 23 Aug 2011 04:05:51 +0200

> Yes, a residential gateway MAY decide not to start the DHCPv6 client if there are no router advertisements to process.  Without any default routers on the WAN link, a DHCPv6 lease from the network…

RAs are not the only mechanism to advertise a default route.
RFC6204, W-3.

cheers,
Ole

---

From: "Frank Bulk" <[email-masked]>
Date: Mon, 22 Aug 2011 21:59:03 -0500

The packet captures show RS, but I only see MLDs, not Router responses.  So
I suspect that Router Discovery is not working, either, for the same reason
RAs aren't coming through.

Frank

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Monday, August 22, 2011 9:06 PM
To: james woodyatt
Cc: [email-masked]; IPv6 Operations
Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit

> Yes, a residential gateway MAY decide not to start the DHCPv6 client if
there are no router advertisements to process.  Without any default routers
on the WAN link, a DHCPv6 lease from the network won't be very useful to a
residential gateway.

cheers,
Ole

---

From: "STARK, BARBARA H (ATTSI)" <[email-masked]>
Date: Tue, 23 Aug 2011 12:58:36 -0400

> Doing a quick look, I didn't see anything more that detailed the

The flowchart in BBF TR-124i2 A.2 is mandatory/normative:
WAN.IPv6. 1 The device MUST support automated establishment of an IPv6
connection according to the flow in Annex A.2.

Yes, in BBF we concluded that the quickest connectivity establishment by
a CE router would be achieved through simultaneous RS and DHCPv6
solicit, and we couldn't identify any good reason why this shouldn't be
done. 

As Ole mentioned on this thread, there are other ways to determine the
default route, so the RA often isn't even needed.

However...
As TR-124i2 A.2 is currently written, not getting the RA is a failure
case. It was so long ago, that I can't remember the discussion, but I
think that it was thought that there was nothing we knew of preventing a
service provider from sending RA messages. This blocking of RA is
curious. But the flow chart A.2 seems pretty clear that the WAN IP
interface is considered "down" in the absence of an RA. I thought there
had been discussion around changing that, but that is what the published
doc says. [Note that since this doc was liaised to IETF with request for
feedback, if any, I do consider discussion of this liaised doc to be a
valid topic, here. Thank you for the feedback.]

But to bring the discussion back to IETF docs...
Yes, RFC 6204 allows the RG to send the DHCPv6 solicit message without
having received the RA (implicit in WPD-5), but it doesn't mandate that
behavior.
Barbara

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 23 Aug 2011 13:34:09 -0500

IMO, it is naïve for a node to issue DHCPv6 SOLICIT without knowing where to send it to. IOW, the node must know where the router is reachable. Receiving RA is one sure way to resolve that, but not the only way. 

However, RFC 6204 doesn't list what other ways could be possible in W-3:

   W-3:  Absent other routing information, the IPv6 CE router MUST use
         Router Discovery as specified in [RFC4861] to discover a
         default router(s) and install default route(s) in its routing
         table with the discovered router's address as the next hop.

Cheers,
Rajiv

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> STARK, BARBARA H (ATTSI)
> Sent: Tuesday, August 23, 2011 12:59 PM
> To: Bernie Volz (volz); [email-masked]; IPv6 Operations

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 23 Aug 2011 13:50:33 -0500

>where to send it

Huh? A node always sends SOLICIT messages to ff02::1:2 so it knows exactly where to send it.

- Bernie

-----Original Message-----
From: Rajiv Asati (rajiva) 
Sent: Tuesday, August 23, 2011 2:34 PM
To: STARK, BARBARA H (ATTSI); Bernie Volz (volz); [email-masked]; IPv6 Operations
Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit

Cheers,
Rajiv

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 23 Aug 2011 14:15:50 -0500

It wasn't about the destination IP address, rather about selecting the right port/interface (if there are 2+ interfaces on the node).

Cheers,
Rajiv

> From: Bernie Volz (volz)
> Sent: Tuesday, August 23, 2011 2:51 PM
> To: Rajiv Asati (rajiva); 'STARK, BARBARA H (ATTSI)'; [email-masked]';
> 'IPv6 Operations'
> IMO, it is naïve for a node to issue DHCPv6 SOLICIT without knowing where to
> send it to. IOW, the node must know where the router is reachable. Receiving
> RA is one sure way to resolve that, but not the only way.
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 23 Aug 2011 14:19:20 -0500

For some devices it is obvious ... like for a device with a WAN interface.

-----Original Message-----
From: Rajiv Asati (rajiva) 
Sent: Tuesday, August 23, 2011 3:16 PM
To: Bernie Volz (volz); 'STARK, BARBARA H (ATTSI)'; [email-masked]'; 'IPv6 Operations'
Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit

Cheers,
Rajiv

---

From: Ole Troan <[email-masked]>
Date: Tue, 23 Aug 2011 21:20:25 +0200

> For some devices it is obvious ... like for a device with a WAN interface.

indeed, and that's the whole model for RFC6204.

cheers,
Ole

---

From: james woodyatt <[email-masked]>
Date: Tue, 23 Aug 2011 12:39:27 -0700

On Aug 23, 2011, at 11:34 , Rajiv Asati (rajiva) wrote:
> 
> However, RFC 6204 doesn't list what other ways could be possible in W-3

Consider the case where the WAN interface is attached to a point-to-point link.  For a residential gateway device, it's probably a reasonable assumption that the other end of such a link is always a default router.

For a multi-purpose gateway device, however, it's not be a reasonable assumption that the other end of an otherwise unidentifiable point-to-point link is a default router.  Hence, the express permission for a residential gateway, which may happen to be a multi-function device deployed in a residential setting, to wait for a router advertisement before proceeding to the DHCPv6 solicit.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 23 Aug 2011 14:46:54 -0500

James,

> Consider the case where the WAN interface is attached to a
point-to-point
> link.  For a residential gateway device, it's probably a reasonable
assumption
> that the other end of such a link is always a default router.

Sure. And xDSL would well qualify as that point-to-point WAN interface.
Can we make that assumption for Wireless and Cable/DOCSIS? 

> For a multi-purpose gateway device, however, it's not be a reasonable
> assumption that the other end of an otherwise unidentifiable
point-to-point
> link is a default router.  Hence, the express permission for a
residential
> gateway, which may happen to be a multi-function device deployed in a
> residential setting, to wait for a router advertisement before
proceeding to
> the DHCPv6 solicit.

Agreed. That's surely the de facto method. BTW, do we allow static
config of the next-hop router for triggering the DHCPv6 solicit?

Cheers,
Rajiv

> From: james woodyatt [mailto:[email-masked]]
> Sent: Tuesday, August 23, 2011 3:39 PM
> To: Rajiv Asati (rajiva)
> Cc: IPv6 Operations
> Consider the case where the WAN interface is attached to a
point-to-point
> link.  For a residential gateway device, it's probably a reasonable
assumption
> that the other end of such a link is always a default router.
> 
> For a multi-purpose gateway device, however, it's not be a reasonable
> assumption that the other end of an otherwise unidentifiable
point-to-point
> link is a default router.  Hence, the express permission for a
residential
> gateway, which may happen to be a multi-function device deployed in a
> residential setting, to wait for a router advertisement before
proceeding to
> the DHCPv6 solicit.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 Aug 2011 13:00:22 -0700

AFAICT, the RA 'M' bit is just one way the RG can
learn that stateful services are available. If the
RG has some other way of knowing that stateful
services are available, then I don't see a problem
for it to invoke DHCPv6 whether or not it ever gets
an RA. Do I have that right?

Thanks - Fred
[email-masked]

---

From: james woodyatt <[email-masked]>
Date: Tue, 23 Aug 2011 13:05:13 -0700

On Aug 23, 2011, at 12:46 , Rajiv Asati (rajiva) wrote:
> 
> do we allow static config of the next-hop router for triggering the DHCPv6 solicit?

Yes, we allow that.  We neither forbid it with "MUST NOT" keywords, nor require any conflicting contingency condition with a "MUST" keyword, in any standards track documents.  The correct answer to the question in the subject line is "when the RG has a reasonable expectation that its DHCPv6 Solicit multicasts will welcomed on the network."  Receiving an M=1 or O=1 in a Router Advertisement is one way of confirming that a DHCPv6 Solicit is welcome on the network.

RFC 6204 mainly addressed to the implementers of dedicated residential gateways.  One of my complaints about that document is that it isn't really suitable for more general application, i.e. for implementers of multi-purpose gateways that can be used in residential settings, which are still quite common in some markets.  I was in the minority about that.

---

From: "Frank Bulk" <[email-masked]>
Date: Tue, 23 Aug 2011 15:19:35 -0500

The RG doesn't need it to be stateful for DHCPv6 to be triggered.  The RFC
allow for DHCPv6 Solicit on an O=1.  

And TR-124i2 without an RA at all.

Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Templin, Fred L
Sent: Tuesday, August 23, 2011 3:00 PM
Cc: IPv6 Operations
Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit

Thanks - Fred

---

From: Ole Troan <[email-masked]>
Date: Tue, 23 Aug 2011 22:23:27 +0200

> And TR-124i2 without an RA at all.

as does RFC3633.

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 Aug 2011 13:51:03 -0700

Right - I forgot about stateless as well as stateful.
Still, if no RS/RA exchange takes place I think the
RG should at least have some inkling that the service
is available. Either that, or the RG should be able
to deal with failure if it blindly invokes the
service and gets no reply.

Thanks - Fred

> Sent: Tuesday, August 23, 2011 1:23 PM
> To: [email-masked]
> Cc: Templin, Fred L; IPv6 Operations
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of
> > Templin, Fred L

---

From: james woodyatt <[email-masked]>
Date: Tue, 23 Aug 2011 14:16:57 -0700

On Aug 23, 2011, at 13:51 , Templin, Fred L wrote:
> 
> Either that, or the RG should be able to deal with failure if it blindly invokes the service and gets no reply.

Yeah.  The way the BBF has written their specifications, the way I'm going to "deal with failure" is to keep retrying forever.  The specification doesn't give me any alternative.  Don't plug residential gateways into networks where DHCPv6 solicits are unwelcome.  The network administrators will disable your port, and there isn't anything I can do about it.  Thanks for playing.

---

From: "Frank Bulk" <[email-masked]>
Date: Tue, 23 Aug 2011 17:25:22 -0500

According to the specs, RGs may blindly make that DHCPv6 Solicit.  

Frank

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Tuesday, August 23, 2011 3:51 PM
To: Ole Troan; [email-masked]
Cc: IPv6 Operations
Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit

Thanks - Fred

---

From: Philip Homburg <[email-masked]>
Date: Wed, 24 Aug 2011 14:23:37 +0200

In your letter dated Tue, 23 Aug 2011 12:39:27 -0700 you wrote:
>Consider the case where the WAN interface is attached to a point-to-point link
>.  For a residential gateway device, it's probably a reasonable assumption tha
>t the other end of such a link is always a default router.
>
>For a multi-purpose gateway device, however, it's not be a reasonable assumpti
>on that the other end of an otherwise unidentifiable point-to-point link is a 
>default router.  Hence, the express permission for a residential gateway, whic
>h may happen to be a multi-function device deployed in a residential setting, 
>to wait for a router advertisement before proceeding to the DHCPv6 solicit.

What's the point of not sending those DHCPv6 solicitations? It can't be
security. It can't be the cost of the network traffic. You have to send the
router solicitations anyhow.

---

From: "STARK, BARBARA H (ATTSI)" <[email-masked]>
Date: Wed, 24 Aug 2011 14:56:59 -0400

> > Either that, or the RG should be able to deal with failure if it
> blindly invokes the service and gets no reply.
> 
> Yeah.  The way the BBF has written their specifications, the way I'm
> going to "deal with failure" is to keep retrying forever.  The
> specification doesn't give me any alternative.  Don't plug residential
> gateways into networks where DHCPv6 solicits are unwelcome.  The
> network administrators will disable your port, and there isn't
anything
> I can do about it.  Thanks for playing.

<sigh> BBF TR-124i2 is written to (a) provide guidance to vendors who
supply RG-type devices to service providers who consider BBF specs
useful to their access network architecture, and (b) provide those same
service providers with a set of requirements that they can use in
procuring RG-type devices for use in their networks.

Which means: If you don't want an RG that is developed per TR-124i2,
don't ask for it; and if you don't want to supply to such service
providers, the document is irrelevant to you.

There are many service providers who consider BBF specs useful who are
deploying PON technology in their access networks. I would indeed
suspect that many RGs that are intending to be used with PON access
networks would abide by TR-124i2.

The service providers who participate in BBF all stated that they wanted
to use IA_PD for prefix assignment to RGs. Thus, for automated setup,
they want the RG to always request IA_PD. IA_PD is stateful. The RA "M"
flag is not considered relevant to IA_PD. To reduce time needed to get
configured, it was decided that IA_PD needed to be requested as soon as
the layer below IP (Ethernet or PPPoE in most BBF cases) was "up". To
reduce the number of Solicit messages and keep the decision tree as
small as possible, it was decided that IA_NA needed to be requested in
the same message. The RG logic doesn't care whether or not IA_NA is
returned. It's happy either way, as long as it gets IA_PD. The RG logic
does care if it doesn't get IA_PD. You are correct that the RG will
continue requesting IA_PD. And that is the behavior service providers
wanted.

If an RG is not receiving IA_PD from a BBF-defined IPv6-enabled access
network, then the assumption is that either the access link is down, or
the access network elements aren't responding. Once the service provider
fixes whatever the problem is, the service provider wants the RG to have
its IPv6 connection established / re-established ASAP.

BBF-defined RGs are intended to work in BBF-defined access networks. You
are absolutely correct that they were not defined with "networks where
DHCPv6 solicits are unwelcome" in mind. Perhaps providers of such
networks, together with the vendors of such networks, need to get
together and define their own set of requirements. 
Barbara

---

From: james woodyatt <[email-masked]>
Date: Wed, 24 Aug 2011 12:21:18 -0700

On Aug 24, 2011, at 05:23 , Philip Homburg wrote:
> 
> What's the point of not sending those DHCPv6 solicitations? It can't be security. It can't be the cost of the network traffic. You have to send the router solicitations anyhow.

Router solicitations are limited in number.  On a network where DHCPv6 is persistently unavailable, I'm going to send solicit multicasts to ff02::1:2 at the maximum allowed rate indefinitely, i.e. with MRT=SOL_MAX_RT(120 s) and MRC=0 as RFC 3315, section 17.1.2 recommends.

Many enterprise network administrators discourage overly chatty devices that send unwelcome multicast packets, even to groups without any members, by shutting down layer-2 ports with devices connected to them that exhibit inappropriate behavior.  Believe it or not, some of these enterprise networks do not use DHCPv6 servers, and do not plan to do so.  Our products that are required to comply with the recommendations of RFC 6204 will be unwelcome on those networks unless we burden the user with additional configuration complexity by forcing them to make an incomprehensible choice of DHCPv6 client behaviors.  That will never happen in a million years, so the answer will be: don't plug those boxes into those ports if you don't want to make IS&T mad at you.  Either that, or we decide not to comply with RFC 6204.

Not sure which way we will go.  Probably the one that the marketing people decide is right.

---

From: Ole Troan <[email-masked]>
Date: Wed, 24 Aug 2011 22:39:15 +0200

James,

I haven't met any Enterprise IT manager who is overly happy about random users plugging in routers and building their own shadow network.
RFC6204 is written for a very specific scenario. it is not a general solution for "how to build a self organising network".

cheers,
Ole

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 24 Aug 2011 22:46:36 +0200

Hi Ole,

My observation here is that what you call "a router" today is a piece of
brick like equipment.

I think routing functionality can be build into and present in much more
variety of equipment types which we like it or not will be randomly
plugged in and what's worse .. expected to work :) I think perhaps piece
of that vision is what James had in mind.

Cheers,
R.

> James,
> 
> I haven't met any Enterprise IT manager who is overly happy about
> random users plugging in routers and building their own shadow
> network. RFC6204 is written for a very specific scenario. it is not a
> general solution for "how to build a self organising network".
> 
> cheers, Ole
> 
> 
>>> What's the point of not sending those DHCPv6 solicitations? It
>>> can't be security. It can't be the cost of the network traffic.
>>> You have to send the router solicitations anyhow.
>> 
>> Router solicitations are limited in number.  On a network where
>> DHCPv6 is persistently unavailable, I'm going to send solicit
>> multicasts to ff02::1:2 at the maximum allowed rate indefinitely,
>> i.e. with MRT=SOL_MAX_RT(120 s) and MRC=0 as RFC 3315, section
>> 17.1.2 recommends.
>> 
>> Many enterprise network administrators discourage overly chatty
>> devices that send unwelcome multicast packets, even to groups
>> without any members, by shutting down layer-2 ports with devices
>> connected to them that exhibit inappropriate behavior.  Believe it
>> or not, some of these enterprise networks do not use DHCPv6
>> servers, and do not plan to do so.  Our products that are required
>> to comply with the recommendations of RFC 6204 will be unwelcome on
>> those networks unless we burden the user with additional
>> configuration complexity by forcing them to make an
>> incomprehensible choice of DHCPv6 client behaviors.  That will
>> never happen in a million years, so the answer will be: don't plug
>> those boxes into those ports if you don't want to make IS&T mad at
>> you.  Either that, or we decide not to comply with RFC 6204.
>> 
>> -- james woodyatt <[email-masked]> member of technical staff, core
>> os networking
>> 
>> 
>> 
>> _______________________________________________ v6ops mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
> 
>

---

From: Ole Troan <[email-masked]>
Date: Wed, 24 Aug 2011 22:51:50 +0200

Robert,

> of that vision is what James had in mind.

sure, that's what homenet is going to work on, at least partly.
but, specifically out of scope for 6204/TR124i2 that was discussed here.

that James still would have liked it within scope is another discussion. ;-)

cheers,
Ole

---

From: james woodyatt <[email-masked]>
Date: Wed, 24 Aug 2011 15:48:05 -0700

On Aug 24, 2011, at 1:39 PM, Ole Troan wrote:
> 
> RFC6204 is written for a very specific scenario.

As I predicted would happen, it's being weaponized for more general scenarios even as we speak.

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 25 Aug 2011 00:54:52 +0000

FWIW this scenario has the opportunity to introduce some interesting
challenges when deploying IPv6.  Certain operating system do as described
below and send DHCPv6 at some interval and if they are not responded to a
number of retries are attempted with an exponential back off between each.
 When this is multiplied by a large number this creates an even larger
volume of DHCPv6 requests.

As such I have a bit stronger of an opinion regarding the use of the M and
O bits, in particular the lengthy debate that occurred some time ago.  I
believe there is value in having M and/or O trigger the use of DHCPv6.
When we specified IPv6 for DOCSIS we decided to use the M bit to trigger
DHCPv6 for cable modems, this works rather nicely.  I am thinking it might
be useful to take this a step further and suggest that the interval which
a device receives an RA with M and/or O be factored into the frequency of
DHCPv6 attempts (not just the retries).

The same would also apply to a RG/IGD via its WAN interface.

John
=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:[email-masked]
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 25 Aug 2011 00:58:32 +0000

James,

Add exponential back offs and the volume of DHCPv6 messages grows
exponentially.  Just sent some mail on this when replying to another
thread.

John

On 8/24/11 3:21 PM, "james woodyatt" <[email-masked]> wrote:

>Router solicitations are limited in number.  On a network where DHCPv6 is
>persistently unavailable, I'm going to send solicit multicasts to
>ff02::1:2 at the maximum allowed rate indefinitely, i.e. with
>MRT=SOL_MAX_RT(120 s) and MRC=0 as RFC 3315, section 17.1.2 recommends.

---

From: "Frank Bulk" <[email-masked]>
Date: Wed, 24 Aug 2011 20:25:47 -0500

I think the cat is out of the bag with the (more liberal) specifications
that already release and devices in production.  

Is your concern a DHCPv6 multicast storm?

Frank

-----Original Message-----
From: Brzozowski, John [mailto:[email-masked]] 
Sent: Wednesday, August 24, 2011 7:55 PM
To: [email-masked]; Fred Templin; Ole Trøan
Cc: IPv6 Operations
Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit

John

---

From: james woodyatt <[email-masked]>
Date: Wed, 24 Aug 2011 20:18:34 -0700

On Aug 24, 2011, at 13:46 , Robert Raszuk wrote:
> 
> ...which we like it or not will be randomly plugged in and what's worse .. expected to work :)

One of the design principles I learned early on in my career is that when most ordinary people find a jack that will accept a plug, or likewise they find a plug that will fit a jack, they will often form very powerful expectations in their minds about what should happen if they insert the plug into the jack. Perhaps, more significantly, I learned that ignoring or defying these expectations is not a good way to make your designs more acceptable to them.

The best way to signal to said ordinary people that they shouldn't expect anything useful to happen by inserting this plug into that jack is to assign the job to a mechanical engineer.  People seem to understand that delicate electronics gear shouldn't require a hammer and pliers to close the network connection loops.

Sadly, this is not the design principle one finds employed most often in the engineering of devices with IEEE 802.1 interfaces.  The common practice in our field is to put identical connectors on everything, occasionally label them with cryptic terminology-- but often we leave them entirely unlabeled.  Next, we give people configuration menus that make the space shuttle cockpit look like a child's toy, and we require them to read a corpus of documentation that weighs in at the kilograms and describes whole new languages and obscure protocols, like some kind of crazy technocratic freemasonry on an acid bender.  Finally, after abusing them in this fashion, we then have the exceedingly poor taste to invite them to *enjoy* all these wonderful opportunities to build puzzles for themselves, their family and friends, and their neighbors, these *beautiful* puzzles which we have gifted to them in our glorious magnanimity.  When they object to this, we call them stupid and ungrateful-- sometimes even in public places, where strangely, we often believe they don't see us doing it-- but, oh, they see us.  They do.  They most certainly do.

I suspect trained psychologists would describe our usual design mode as a form of sociopathic behavior.

> I think perhaps piece of that vision is what James had in mind.

Absolutely.

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 25 Aug 2011 03:48:14 +0000

Concern is not multicast storms. High volumes of relayed unicast DHCPv6.

Not sure what you are referring to WRT specifications, etc.

Frank Bulk <[email-masked]> wrote:

Frank

-----Original Message-----
From: Brzozowski, John [mailto:[email-masked]]
Sent: Wednesday, August 24, 2011 7:55 PM
To: [email-masked]; Fred Templin; Ole Trøan
Cc: IPv6 Operations
Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit

John

---

From: "Frank Bulk" <[email-masked]>
Date: Wed, 24 Aug 2011 22:51:56 -0500

DHCPv6 Solicits are multicast.  I don't know myself, but I'm guessing then
that the CMTS has a relay agent that converts it to unicast.

Frank

-----Original Message-----
From: Brzozowski, John [mailto:[email-masked]] 
Sent: Wednesday, August 24, 2011 10:48 PM
To: [email-masked]
Cc: IPv6 Operations
Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit

Frank

-----Original Message-----
From: Brzozowski, John [mailto:[email-masked]]
Sent: Wednesday, August 24, 2011 7:55 PM
To: [email-masked]; Fred Templin; Ole Trøan
Cc: IPv6 Operations
Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit

John

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Aug 2011 03:58:06 +0000

On Aug 24, 2011, at 8:58 PM, Brzozowski, John wrote:
Add exponential back offs and the volume of DHCPv6 messages grows
exponentially.  Just sent some mail on this when replying to another
thread.

This doesn't make sense.   The point of exponential backoff is that traffic should shrink over time, not grow.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Aug 2011 04:00:54 +0000

On Aug 24, 2011, at 11:18 PM, james woodyatt wrote:
The best way to signal to said ordinary people that they shouldn't expect anything useful to happen by inserting this plug into that jack is to assign the job to a mechanical engineer.  People seem to understand that delicate electronics gear shouldn't require a hammer and pliers to close the network connection loops.

Yeah, this has been weighing on my mind a bit lately.   Why *don't* we use different connectors for different purposes?

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 25 Aug 2011 04:01:27 +0000

This is what I was loosely referring to, sorry for not being clear. Regardless, the M and/or O is what I was referring to relative to DHCPv6.

Frank

-----Original Message-----
From: Brzozowski, John [mailto:[email-masked]]
Sent: Wednesday, August 24, 2011 10:48 PM
To: [email-masked]
Cc: IPv6 Operations
Subject: RE: [v6ops] When an RG should issue a DHCPv6 solicit

Frank

-----Original Message-----
From: Brzozowski, John [mailto:[email-masked]]
Sent: Wednesday, August 24, 2011 7:55 PM
To: [email-masked]; Fred Templin; Ole Trøan
Cc: IPv6 Operations
Subject: Re: [v6ops] When an RG should issue a DHCPv6 solicit

John

---

From: Philip Homburg <[email-masked]>
Date: Thu, 25 Aug 2011 13:36:20 +0200

In your letter dated Wed, 24 Aug 2011 12:21:18 -0700 you wrote:
>> What's the point of not sending those DHCPv6 solicitations? It can't be secu
>rity. It can't be the cost of the network traffic. You have to send the router
> solicitations anyhow.
>
>Router solicitations are limited in number.  On a network where DHCPv6 is pers
>istently unavailable, I'm going to send solicit multicasts to ff02::1:2 at the
> maximum allowed rate indefinitely, i.e. with MRT=SOL_MAX_RT(120 s) and MRC=0 
>as RFC 3315, section 17.1.2 recommends.
>
>Many enterprise network administrators discourage overly chatty devices that s
>end unwelcome multicast packets, even to groups without any members, by shutti
>ng down layer-2 ports with devices connected to them that exhibit inappropriat
>e behavior.  

I don't know how that is defined. But if you would disable able any device that
multicasts more than DHCPv6 then would quickly have an network without Windows
or OSX. 

I assume that when a router is connected, it is meant to be used. If it isn't
it doesn't really matter if the router's ports are shutdown at the l2.

One exception maybe an IPv6 capable router in an IPv4-only environment. I'd
say, let the router just try to do IPv6 and have someone explictly disable
IPv6 if that causes to much noise.

But I can also imagine vendors implementing that the other way around for the 
moment.

------- End of Forwarded Message

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 25 Aug 2011 13:53:01 +0000

I understand, however as enablement progresses more devices that are IPv6
enabled continue to transmit requests.  This multiplied by the fact that
these devices systematically attempt to reinitialize DHCPv6 every "n"
minutes generates a lot of traffic.  Even with the exponential back off
between SOLICITs.

Consider the following:

* every "n" minutes
* a series of DHCPv6 SOLICITs are sent exponentially backing off between
each

The more devices doing this generates lots of traffic.  If M and O were in
place to influence the behavior the same could be set to influence the
behavior of the clients.  Further, if the rate or frequency of RAs with M
and/or O set to 1 further altered the rate of DHCPv6 requests there could
be added benefit.

On 8/24/11 11:58 PM, "Ted Lemon" <[email-masked]> wrote:

>Add
> exponential back offs and the volume of DHCPv6 messages grows
>This doesn't make sense.   The point of exponential backoff is that
>traffic should shrink over time, not grow.
>
>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 25 Aug 2011 09:09:27 -0500

+1, and in the access, the bandwidth is not always cheap. So, whatever
we can do to save bandwidth from unnecessary usage, we should seriously
consider that.

I continue to think that keep sending SOLICIT without even knowing where
the router is, and whether the router is available for serving DHCPv6,
is not an optimal recipe.

Cheers,
Rajiv

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Brzozowski, John
> Sent: Thursday, August 25, 2011 9:53 AM
> To: Ted Lemon
> Cc: IPv6 Operations

---

From: Ole Troan <[email-masked]>
Date: Thu, 25 Aug 2011 16:41:46 +0200

> we can do to save bandwidth from unnecessary usage, we should seriously

one packet every 120 seconds, that gets discarded at the first hop?
if we're that concerned about saving bandwidth I would pick a few lower hanging fruits.

> is not an optimal recipe.

"the router", what router?

cheers,
Ole

---

From: Erik Kline <[email-masked]>
Date: Fri, 26 Aug 2011 00:20:46 +0900

> and/or O set to 1 further altered the rate of DHCPv6 requests there could

<snarky>
And how much traffic is generated if you just answer these requests?  ;-)
</snarky>

---

From: "Lee Howard" <[email-masked]>
Date: Thu, 25 Aug 2011 13:37:35 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
james
> woodyatt
> Sent: Wednesday, August 24, 2011 11:19 PM
> To: IPv6 Operations
> > ...which we like it or not will be randomly plugged in and what's worse
.. expected to
> work :)
> 
> The best way to signal to said ordinary people that they shouldn't expect
anything useful to
> happen by inserting this plug into that jack is to assign the job to a
mechanical engineer.
> People seem to understand that delicate electronics gear shouldn't require
a hammer and
> pliers to close the network connection loops.

If we built a smiley-face plug for Homenet use, somebody would invent a
smiley-to-RJ45 
dongle.  Also out of scope is the sadness people will feel if they plug
their Ethernet RJ45 
into a T1 jack, or their MoCA interface into Arcnet.

When I was an IT guy, I shut down unauthorized routers where I found them.
If I still 
were one, I would:
* not respond to IA_PD requests, 
* continue tracking/removing unauthorized routers as I found them
* not worry about the volume of DHCPv6 SOLICITs on my LAN

If IT administrators wants to use Homenet boxes to build their network,
they're going
to have limitations.  Some of those may be remedied with a different
software build,
(designed for commercial use) in which case they might actually be happy to
have RJ45s
instead of smiley plugs.

Can we move this to Homenet?

Lee