Subject: Re: review of draft-ietf-node-req-bis

From: Thomas Narten <[email-masked]>
Date: Thu, 26 May 2011 16:21:59 -0400

Going back to this...

Jari Arkko <[email-masked]> writes:

> I have reviewed this draft. In general, this version is well written,
> I agree with the recommendations, and I'd like to thank everyone for
> working on this much needed update. I think the document is ready to
> go to IETF Last Call -- some minor issues below that I think could be
> addressed even during the last call.

> However, since I was part of the original design team that worked RFC
> 4294, I have asked Ralph to formally handle this document. He has
> promised to do so. (Thanks!)
> 
> My comments:
> 
> 
>     Consequently, IPv6 Jumbograms [RFC2675
>     <http://tools.ietf.org/html/rfc2675>] remain optional at this
>     time.
> 
> Other sections use RFC 2119 keywords (MAY) to state this. Consider
> using that style here as well.

I'd rather not make this change. I think MAY sounds stilted. In
addtion, the defintion of MAY is "optional":

   5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

>     Static address may be supported as well.
> 
> "Static addresses may be ..." or "Configuration of static address(es)
> may be ..." might be a better formulation.

Agreed.

>     For general purpose devices, RFC 4429 is not considered to be
>     necessary at this time.
> 
> Hmm. I'd argue that moving and sleeping/waking nodes is perhaps more
> the norm than exception today. At the very least, I'd again use the
> MAY keyword for this specification. The above sounds almost like
> recommending to not implement it.

Changed last sentence to:

      For general purpose devices, RFC 4429 remains optional at this
      time.
      
>     Consequently, DNS configuration
>     information can now be learned either through DHCP or through RAs.
>     Hosts will need to decide which mechanism (or whether both) should be
>     implemented.
> 
> I would make a forward reference here and add: "Specific guidance
> regarding DNS server discovery is discussed in Section 7." This is
> because for that specific issue we do have something stronger to say
> than the above text .

Done.

> (And based on my own experience of running non-IPv4 networks that
> desperately need DNS discovery, somewhere in Section 7 I think you
> should require that routers with attached hosts actually support both
> (stateless) DHCP and RA-based DNS discovery.)

New text:

   12.3.  Stateful Address Autoconfiguration (DHCPv6) - RFC 3315

   Because a single DHCP server can support devices on multiple links,
   it is not necessary that every router support DHCPv6 directly.
   However, in order to support DHCPv6 servers on other links, routers
   SHOULD support relay agent functionality of DHCPv6 [RFC3315].
   Routers MAY support full [RFC3315] or stateless [RFC4862] DHCPv6
   server functionality as well.

I'm on the fence wrt MAY/SHOULD on the recommendation above. I don't
think every router needs to support DHCP, hence the MAY. But SHOULD is
also not a MUST, so I'd be OK with SHOULD.

Indeed, where one arguably should have a MUST is in relay agent
functionality. SHould I elevate it?

Thoughts?

Thomas

---

From: Bob Hinden <[email-masked]>
Date: Thu, 26 May 2011 14:05:57 -0700

Thomas,

> functionality. SHould I elevate it?

I think SHOULD is more appropriate.  There are going to be environments where it's not needed.  

Bob

---

From: Mark Smith <[email-masked]>
Date: Fri, 27 May 2011 06:56:26 +0930

Hi Thomas,

On Thu, 26 May 2011 16:21:59 -0400

> Jari Arkko <[email-masked]> writes:
<snip>
> functionality. SHould I elevate it?

I think relay should be a MUST. I want to see IPv6 achieve the same
level of autoconfiguration that previous protocols like Appletalk and
IPX achieved, which includes automated application/service parameter
configuration. If the application/service parameter source is off
link (i.e. an off-link DHCPv6 server), then currently the only way for
those options to passed opaquely to end-nodes via a router is via a
DHCPv6 relay capability.

I've recently realised "route constraint" is currently a problem in an
SP environment. As an SP, you want to automate as much as possible the
configuration of all the services you provide to customers, such as
providing DNS, SIP, NTP etc. parameters. If you add another service, and
therefore add another DHCPv6 option to be provided to end-nodes, you
need to have that new option get to the end-nodes for those that are
interested in it, meaning that new option needs to "traverse" the CPE.
However, currently the CPE RFC only says that the LAN interface should
implement a DHCPv6 server, and provide options to the end-nodes using
the options that the CPE has leaned via the DHCPv6-PD transaction on
the WAN interface. This means that if the CPE doesn't support the new
DHCPv6 option for the new service you've deployed, then the end-nodes
can't be provided with that DHCPv6 option despite them supporting it. In
a market where customers own and operate the CPE, the only DHCPv6
options a SP can therefore rely on being supported in CPE is likely to
be no more than DNS addresses. For markets where the CPE is owned and
operated by the SP, it still means a firmware update, supporting the
new DHCPv6 option, has to be deployed to all CPE before the application
can be deployed. In other words, a device in the network now constrains
the deployment of a new application on the end-nodes. I think that
situation is actually violating one of the most valuable principles of
the Internet - that new application deployment doesn't have a dependency
on the deployment of new capabilities in the network.

So I think a DHCPv6 relay in routers should be a MUST. Somewhat off
topic but related, I'm also thinking there should be a DHCPv6 option to
convey one or more DHCPv6 server addresses that is learned by CPE
during the DHCPv6-PD transaction, with the DHCPv6 server then used for
a DHCPv6 relay operating on the LAN interface. An SP can then have the
CPE LAN interface DHCPv6 relays pointing to a nominated off-link DHCPv6
server (the default without this new option could be the DHCPv6(-PD)
server), which would allow CPE unsupported DHCPv6 options to
transparently traverse the CPE, directly reaching the end-nodes.

Regards,
Mark.

---

From: Thomas Narten <[email-masked]>
Date: Thu, 26 May 2011 17:30:10 -0400

Mark Smith <[email-masked]> writes:

> I think relay should be a MUST.

Let me ask a question. In IPv4, for typical SOHO routers, do they
support DHCP relay agent functionality? (My guess is no.)

And what about configuring it? It is *not* plug and play, zeroconf
magic...

Thomas

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 26 May 2011 16:46:02 -0500

> And what about configuring it? It is *not* plug and play, zeroconf

Since they are typically NAPTs, I'd say no. They are local DHCP servers for the private address space behind them only.

In IPv6, what will the "typical SOHO router" look like, though? Same NAT functionality as IPv4? And if not, is there an automatic way of configuring this SOHO router for any possible DHCP relay function?

I agree with Thomas that a MUST involves consequences that need to be addressed first.

Bert

---

From: Mark Smith <[email-masked]>
Date: Fri, 27 May 2011 07:33:27 +0930

Hi Thomas,

On Thu, 26 May 2011 17:30:10 -0400

> support DHCP relay agent functionality? (My guess is no.)

I don't think they do, but I'm not sure why it matters. Aren't we
talking about minimum IPv6 functionality that can be relied on being
present? What has been deployed in IPv4 can be a guide (as can the past
deployment of Appletalk and IPX where IPv6 has similar capabilities),
but I don't think IPv4 deployment should be an overarching constraint
on what can be done and is available under IPv6.

> And what about configuring it? It is *not* plug and play, zeroconf

Exactly. That's the problem. If you know you can't or aren't very
likely to be able to relay DHCP options to customer's end-nodes, you
don't bother sending them. The myriad of DHCP(v4 and v6) options that
exist that may be useful to an SP are currently of no or very little use
because they can't be conveyed directly to customer's end-nodes across
the CPE boundary.

If an SP can convey DHCPv6 options "past the CPE" to the end-nodes,
then IPv6 operation in the customers home can much more user friendly
than IPv4's has been. And it needs to be. We've been able to get away
with asking customers to type in IPv4 addresses, we won't get away with
asking them to type in IPv6 addresses, and we shouldn't be asking them
to manually type in DNS names when automated methods of providing them
already exist. We just need to make them usable.

SOHO CPE are the most common routers deployed, so I think any IPv6
router requirements minimums should be primarily guided by their
functional requirements.

Regards,
Mark.

---

From: Doug Barton <[email-masked]>
Date: Thu, 26 May 2011 15:47:04 -0700

> because they can't be conveyed directly to customer's end-nodes across

One could imagine a situation where the CPE makes configures itself with 
those options, and by default then transmits them to clients it acts as 
a server for. That is probably a different document though.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Cutler James R <[email-masked]>
Date: Thu, 26 May 2011 21:32:06 -0400

On May 26, 2011, at 5:26 PM, Mark Smith wrote:

> <snip/>
> <snip/>

I strongly concur with Mark re "MUST". It does not make sense to design in limitations which would require CPE firmware updates or other extreme measures to overcome later.  If you feel strongly that DHCP relay should be "off by default", by all means make it so.  But, don't design away the capability which some say that their business requires.

IPv6 is supposed to be "just like IPv4, only better".  Deliberately crippled by design is not "better".

James R. Cutler
[email-masked]

---

From: Brian Haberman <[email-masked]>
Date: Fri, 27 May 2011 08:07:28 -0400

On 5/26/11 5:46 PM, Manfredi, Albert E wrote:
> Since they are typically NAPTs, I'd say no. They are local DHCP
> servers for the private address space behind them only.
> 
> In IPv6, what will the "typical SOHO router" look like, though? Same
> NAT functionality as IPv4? And if not, is there an automatic way of
> configuring this SOHO router for any possible DHCP relay function?

What about a situation where rather than using DHCP relay, a router uses
DHCP Prefix Delegation to get a prefix that is then used in the home
network?  There is no need for the relay functionality and the CPE is
still plug-and-play.

Regards,
Brian

---

From: Timothy Winters <[email-masked]>
Date: Fri, 27 May 2011 08:11:37 -0400

Brian suggestion is what we've seen in all the CPE devices we've had at the UNH-IOL last two CE Router Events.  I haven't seen a CPE/SOHO router act as a relay agent.

Regards,
Tim

On May 27, 2011, at 8:07 AM, Brian Haberman wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "STARK, BARBARA H (ATTSI)" <[email-masked]>
Date: Fri, 27 May 2011 09:08:37 -0400

I'm unaware of any member of the mass market community (which accounts
for a whole lot of "nodes" and "routers") who are asking for or wanting
or expecting DNCP Relay. That's SOHO, Consumer, or the ISPs that serve
them. Are there specialized niches inside these communities that might
like DHCP Relay? That could well be. But to suggest that the mass incur
the expense of including DHCP Relay for the benefit of an unknown few is
unrealistic. 

Note that the CableLabs eRouter spec (Feb 2011) says 
"The eRouter is not expected to implement:
...
* Any relay agent functions."

The Broadband Forum TR-124 Issue 2 makes no mention of DHCPv6 Relay,
whatsoever.

Assuming that these documents are a good indication of the functionality
that major connectivity ISPs are expecting in IPv6-capable consumer (and
mass market SOHO to a large extent) routers, I would say that it is
almost a given that if you do make DHCP Relay a "MUST", this would be
one "MUST" that will be blithely ignored by many. Including "MUST"
recommendations that are going to be ignored severely weakens a
document. I would recommend against it.

I would also recommend against a "SHOULD", given the language (or lack
of language) in the above mentioned documents. IMO, "MAY" is fine.

Also, note that we have only just agreed to elevate support for DHCPv6
client in hosts from "MAY" to "SHOULD". If we can't expect hosts to
support DHCPv6 as a "MUST" (and I quite agree with the "SHOULD" level
there), then suggesting DHCPv6 Relay in routers be a "MUST" makes no
sense to me.
Barbara

---

From: Ralph Droms <[email-masked]>
Date: Fri, 27 May 2011 09:25:57 -0400

+1.  It's highly unlikely that an SP wants to field DHCPv6 transactions from all the devices in a subscriber network.  We have adequate mechanisms in place to get delegated prefixes and other config information to the DHCPv6 server in the subscriber network without the DHCPv6 relay function.

I recommend "routers SHOULD support relay agent functionality of DHCPv6 [RFC3315]."  As Ray Hunter pointed out, the market will drive implementation where needed: "I won't buy a router without a DHCPv6 relay function."

- Ralph

---

From: "STARK, BARBARA H (ATTSI)" <[email-masked]>
Date: Fri, 27 May 2011 11:20:14 -0400

> +1.  It's highly unlikely that an SP wants to field DHCPv6
transactions
> from all the devices in a subscriber network.  We have adequate
> mechanisms in place to get delegated prefixes and other config
> information to the DHCPv6 server in the subscriber network without the
> DHCPv6 relay function.
> 
> I recommend "routers SHOULD support relay agent functionality of
DHCPv6
> [RFC3315]."  As Ray Hunter pointed out, the market will drive
> implementation where needed: "I won't buy a router without a DHCPv6
> relay function."

Hmm. I think maybe I need to be just a little stronger in my opposition
to elevating the language around DHCPv6 Relay Agent. From a mass market
service provider perspective, there are many cons to DHCPv6 Relay Agent,
and no pros. In the world of mass market, scalability and capacity are
very important. DHCP servers are scaled (and have the capacity) to
function properly when there is a mass restoral of power after an outage
that impacts many subscribers. If the number of devices sending DHCPv6
queries were increased many-fold, then this would increase the cost of
DHCPv6 servers. In addition, the queries from hosts would likely get in
the way of queries from routers requesting PDs. The routers need those
PDs, and slowing down the PD process with lots of unnecessary and
unwanted queries from hosts is a Bad Thing. Furthermore, if a router
inside the home network requests a PD (many SPs will probably restrict
PD assignment to 1 PD per subscriber) before the customer edge router
does, then the customer's home network could end up in pretty bad shape.

As evidenced by BBF and CableLabs docs, service providers are designing
address assignment architecture around PD. Also, many end users (like
me) would be very uncomfortable with having addresses for home network
assigned directly from a service provider. Personally, I like to think I
have some control over my home network. So DHCPv6 Relay Client for
purpose of address assignment may actually be considered undesirable (by
all parties involved) in a mass market environment.

Furthermore, there is no need for DHCPv6 Relay Client for passing
through options. The mechanisms that most service providers expect to
see in routers is evident in RFC 6204:
"L-12: The IPv6 CE router SHOULD make available a subset of DHCPv6
options (as listed in Section 5.3 of [RFC3736]) received from
the DHCPv6 client on its WAN interface to its LAN-side DHCPv6
server."
And TR-124i2:
"LAN.DHCPv6S.10 The device SHOULD support Reconfigure Accept (RFC 3315)
and pass the additional set of DHCP options received from the
DHCP client on its WAN interface to IPv6 hosts."

Given the above points, it's likely that many mass market service
providers will actively prohibit DHCPv6 Relay Client from existing in
the routers that they procure. You could argue that they could just
disable it. But the reality is, that there is no need for it, and there
could be harm if it were enabled (subscriber: "Ooh, what does this
button do?"), so it's best not to have it at all. That saves on coding,
testing, and risk of accidental enablement.

For the IETF to strongly recommend implementing a function that a large
segment of implementers is likely to actively prohibit doesn't seem like
the right thing to do. And mandate of such a function, IMO, wouldn't
serve the IETF well, at all.
Barbara

---

From: Ralph Droms <[email-masked]>
Date: Fri, 27 May 2011 11:24:58 -0400

Barbara - sorry, I wasn't clear.  I think we're in agreement.  The router at the edge of a subscriber network does not need the relay function.

There are other network architectures where the relay function is likely to be needed.  It's not clear a single RFC 2119 recommendation is adequate.

- Ralph

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 27 May 2011 14:05:14 -0500

> network?  There is no need for the relay functionality and the CPE is

I agree that there are many possible ways to make this work. That's one of them.

My only point was, if DHCPv6 relay will become a MUST, then some other RFC needs to be written to explain how this will be done in an interoperable way, automatically, so that we aren't going to have to rely on manual configurations in these SOHO settings.

Bert

---

From: Mark Smith <[email-masked]>
Date: Sat, 28 May 2011 10:22:23 +0930

Hi Doug,

On Thu, 26 May 2011 15:47:04 -0700

> a server for. That is probably a different document though.

If the CPE doesn't understand the options, it can't pass them on. 

So if you look at the list of DHCPv6 options the are available -

http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml#dhcpv6-parameters-2

currently, using a DHCPv6 server in the CPE, none of them can be
provided to end-nodes if the CPE doesn't support them, despite the SP's
DHCPv6 server supporting them and the SP's customer's end-nodes
supporting them.

Only a DHCPv6 relay can effectively convey (relay) options it
doesn't understand because it doesn't actually try to understand them.

Regards,
Mark.

---

From: Doug Barton <[email-masked]>
Date: Fri, 27 May 2011 18:04:20 -0700

On 05/27/2011 17:52, Mark Smith wrote:
> Doug Barton<[email-masked]>  wrote:
>

Well of course, yeah.

> doesn't understand because it doesn't actually try to understand them.

I understand how relays work, but thanks. :)  You're presuming however 
that both end users and SPs would want this behavior, and that both 
would want it in spite of it being dramatically different than what is 
done currently with IPv4. I don't think either of those is true, but I 
don't have research to back it up.

Doug

--