Subject: Re: [BEHAVE] Comments on draft-wing-behave-learn-prefix-03

From: Dave Thaler <[email-masked]>
Date: Tue, 4 Aug 2009 22:04:16 +0000

At IETF, Dan asked WG participants to comment on the choice of mechanism,
between DNS, DHCP, and RAs.  I've done a bit of research and I'd like to now
provide my recommendation, which is: DHCP.

Rationale:

1) Changing Windows host stacks is not required.  Windows provides a
   public API to get any new DHCP option (e.g., see
   http://msdn.microsoft.com/en-us/library/aa363345(VS.85).aspx for DHCPv4 and
   http://msdn.microsoft.com/en-us/library/aa363327(VS.85).aspx for DHCPv6).
   That means it's just a tool or daemon that anyone could write, and in
   fact it's simpler to write than an RA solution, and either simpler or
   about the same as a DNS solution).

2) Changing DHCP server code is not required.  DHCP servers I'm aware
   of (including Windows and ISC's - see
   http://node1.yo-linux.com/cgi-bin/man2html?cgi_command=dhcp-options)
   allow an administrator to enter arbitrary options (e.g., in hex).
   That means a human can already do it with some effort, and it's
   straightforward to make a user-friendly tool to do it.  This is simpler
   than a RA solution, and about the same as a DNS solution.

3) DHCP is the standard general-purpose mechanism for configuring hosts
   with information that the local router isn't authoritative for, which
   is the scenario here.  Hence it's more appropriate than either DNS or
   RAs, and is consistent with RFC 5505 principles.  Also routers, DHCP
   servers, and DNS servers may be managed by different people in many
   enterprises, and it's the DHCP server administrator that does host
   configuration.

4) If there are folks (not me) that really believe in RA configuration
   for information that the local router isn't authoritative for,
   there's already interest in defining an RA option that can contain
   DHCP options so you don't have to define RA options for all of them.
   So anyone arguing for RAs should be happy here too.

-Dave

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 05 Aug 2009 09:23:35 +0800

Hi Dave,

>    DHCP options so you don't have to define RA options for 

Defining an RA option that can contains DHCP options directly seems a good
idea. Could you please provide any detailed clues?

Thanks,

Xiaohu

---

From: Stig Venaas <[email-masked]>
Date: Thu, 13 Aug 2009 16:20:01 -0700

>    about the same as a DNS solution).

I wish there was a standard way to do this on other platforms. The main
issue I see with DHCP and RA is how to give applications access to the
information in a standard/portable way. With DNS it is easy.

>    than a RA solution, and about the same as a DNS solution.

Agree

>    enterprises, and it's the DHCP server administrator that does host

Agree on this as well, and am also in favour of DHCP.

>    So anyone arguing for RAs should be happy here too.

I'm not sure about this. There may be semantics of DHCP options that
don't easily map to their usage in RAs.

Stig

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

---

From: Dave Thaler <[email-masked]>
Date: Wed, 19 Aug 2009 19:35:27 +0000

There was discussion in the intarea meeting at IETF 74.

Minutes: http://www.ietf.org/proceedings/74/minutes/intarea.txt
Slides: http://www.ietf.org/proceedings/74/slides/intarea-4.pdf

The discussion concluded by saying that defining an RA option that can
contain DHCP options seems like a good idea.  E.g. from the minutes:
"- Krishnan: Pointing out that he wrote a spec on how to share options between DHCP and RA's."

Perhaps Suresh can provide more info here.

-Dave

> -----Original Message-----
> From: Xu Xiaohu [mailto:[email-masked]]
> Sent: Tuesday, August 04, 2009 6:24 PM
> To: Dave Thaler; 'Behave WG'
> Subject: re: [BEHAVE] Comments on draft-wing-behave-learn-prefix-03
>
> Hi Dave,
>

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 19 Aug 2009 15:46:54 -0400

Hi Dave,
   Here is a pointer to that doc.

http://tools.ietf.org/html/draft-krishnan-intarea-ra-dhcp-00

I did not update this document further since there was a possibility of 
redundant (and potentially conflicting) information being passed thru 
this mechanism and dhcpv6 (Section 2.3 of RFC5505) and I did not know 
how to reconcile these pieces of info on the host.

Cheers
Suresh

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 20 Aug 2009 11:30:41 +0800

Hi Dave and Suresh,

Thanks a lot for your valuable information. 

>From the following two drafts, it can be easily concluded that both DHCPv6
and RA have their own markets. The harassment to ISPs is they had to use
these two mechanisms together in some cases because some option defined in
one mechanism has no counterpart in the other one. Either the DHCP carrier
option in RA or the default router option (even the possible RA carrier
option) in DHCPv6 is to deal with the above problem. To avoid redundant
standardization effort, except the idea of DHCP (or RA) carrier option,
another possible way is to unify their TLVs of common options for both RA
and DHCPv6, especially the TLV of a new option (e.g., the prefix64 option),
although the length of their Type/Length field is different from each other
unfortunately.

+++++++++++Some quotes from the following two drafts, 
+++++++++++FYI.++++++++++++++++

In http://tools.ietf.org/html/draft-krishnan-intarea-ra-dhcp-00, there was a
statement as "... Recently there has been interest in doing more of DHCP
work using   Neighbor Discovery (Router Advertisement) messages.  This is
mainly to accomodate environments where DHCP is not available and the only
way of convey configuration information is through RAs."

In http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00,
there was a statement as " In many IPv6 deployments, particularly in edge
networks, end devices obtain configuration information about default
routers, on-link   prefixes and addresses from Router Advertisements as
defined in Neighbor Discovery.  In some deployments, however, there is a
strong desire not to use Router Advertisements at all and to perform all
configuration via DHCP [RFC3315]."
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Xiaohu

> -----邮件原件-----
> 发件人: Suresh Krishnan [mailto:[email-masked]]
> 发送时间: 2009年8月20日 3:47
> 收件人: Dave Thaler
> 抄送: Xu Xiaohu; 'Behave WG'
> 主题: Re: [BEHAVE] Comments on draft-wing-behave-learn-prefix-03
> 
> Hi Dave,
> > "- Krishnan: Pointing out that he wrote a spec on how to share options
between
> DHCP and RA's."

---

From: Stig Venaas <[email-masked]>
Date: Thu, 20 Aug 2009 11:45:12 -0700

> although the length of their Type/Length field is different from each other

There are also examples of DHCPv6 options that would not make sense in
RAs. So one might need to specify which options should be supported.

Stig

---

From: Dave Thaler <[email-masked]>
Date: Thu, 20 Aug 2009 18:54:47 +0000

Stig Venaas wrote:
[...]
> RAs. So one might need to specify which options should be supported.

I would assume the options that would be legal would be
DHCPv6 options that would be legal in a DHCPv6 REPLY message.
Are there examples of such options that would not make sense in
RAs, or is that clarification sufficient?

-Dave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Aug 2009 21:13:19 +0200

> RAs. So one might need to specify which options should be supported.

I'm more concerned about the people who want to add gateway addresses  
to DHCPv6. The fact that there is fait sharing between the device that  
forwards packets and the device that advertises the address of the  
device that forwards packets with RAs (because the two are the same)  
makes IPv6 much more robust than IPv4 where DHCP is almost a given.  
It's remarkable how often, still after more than a decade of  
deployment, DHCP problems create IPv4 outages.

In an ideal world we would retire DHCP because it's too arcane, has  
too many flavors (v4, stateful v6, stateless v6) and is too complex.  
Just pointing towards an HTTP server that has the configuration  
information would be so much better.

But we're stuck with DHCP for IPv4 and we now also need it for prefix  
delegation in IPv6 so we have to live with it. But DHCP should not be  
the go to protocol for all our needs.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 20 Aug 2009 12:36:17 -0700

> RAs, or is that clarification sufficient?

There are several. The most obvious are things that are unique per
client, e.g. the Client FQDN option (RFC 4704). Of course also options
that hand out IP addresses to clients (IA_NA, IA_TA etc). There is also
the Information Refresh Time option (RFC 4242) that tells client more
or less when it next should query the DHCP server. I can find more.

You could maybe say "options that can be in response to DHCP
Information-Request messages", or "Stateless DHCPv6".

But at least the last one I mentioned (RFC 4242), is an example of an
option used in that case that would be meaningless in RAs.

Stig

---

From: Dave Thaler <[email-masked]>
Date: Thu, 20 Aug 2009 19:45:12 +0000

> From: Stig Venaas [mailto:[email-masked]]
> Sent: Thursday, August 20, 2009 12:36 PM
> To: Dave Thaler
> Cc: 'Behave WG'
> Subject: Re: [BEHAVE] DHCPv6 v.s. RA//re: Comments on draft-wing-
> behave-learn-prefix-03
>
> Dave Thaler wrote:
> > Stig Venaas wrote:
> > [...]

The point of the presentation by Thomas/Ralph is that there's apparently
demand for unicast RAs providing different information to different
clients.  So I don't follow why things that are unique per client
would not make sense in a unicast RA.

I would certainly agree with the restriction that a _multicast_ RA
could only contain options sent in response to Information-Request
messages.

-Dave

---

From: Stig Venaas <[email-masked]>
Date: Thu, 20 Aug 2009 13:04:02 -0700

> could only contain options sent in response to Information-Request

OK, if you unicast RAs that would be different. But there are still DHCP
options that are kind of part of the DHCP protocol (like RFC 4242) that
may not make sense.

But also semantics may be a bit different. Some options are sent only
when requested. In some cases, like Client FQDN the client is allowed to
send a partial domain name to the server, and then the server completes
it.

I don't mind adding many of the DHCPv6 options to RAs, but I'm not sure
it is good to have a mechanism allowing any option to be specified where
the implementors have to make guesses as to which options they can
expect and how to handle them.

At least someone should then write some RFC saying which options you
should handle and point out any caveats.

For new options that should be in both DHCPv6 and RA one could possibly
have a single document describing both uses.

Stig

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 21 Aug 2009 18:03:44 +0800

> have a single document describing both uses.

Absolutely agree.

Xiaohu