Subject: Re: [dhcwg] Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt"

From: Ralph Droms <[email-masked]>
Date: Mon, 6 Oct 2008 09:31:23 -0400

Thomas - you wrote:

> unless something  has
> changed (and I have seen no indication of this), the WG should not
> take on this topic or discuss it further because there is no consensus
> to make any changes.

One part of the situation that may have changed - or, perhaps, wasn't  
considered - is the case of implementors reading RFC 486[12] without  
the knowledge of previous discussions of the M/O flags.  How will  
those implementors interpret the text in RFCs 486[12] and 246[12], and  
how will they implement stack behavior for the M/O flags?

I ask because I've gotten questions on exactly this issue.  In my  
opinion, the previous discussions that lead to the current text in RFC  
486[12] came to consensus that:

* M/O bits indicate availability of DHCPv6 services
* client behavior based on the availability based on M/O bits is  
unspecified

I don't think that consensus is clearly described in RFCs 486[12].   
However, I think the problem can be resolved with a couple of  
sentences; e.g.:

* Add a new Note after the description of the M/O flags in Section 4.2  
of RFC 4861:

   Note: The DHCPv6 client behavior in response to the receipt of M  
and O flags is unspecified.

* Add a sentence to the clarification in RFC 4862:

   o Removed the text regarding the M and O flags, considering the  
maturity of implementations
     and operational experiences. ManagedFlag and OtherConfigFlag were  
removed accordingly. (Note
     that this change does not mean the use of these flags is  
deprecated.)  *The DHCPv6 client
     behavior in response to the receipt of M and O flags is  
unspecified.*

* Change the following sentence from Section 3 of RFC 4861:

   For example, routers can specify whether hosts should use DHCPv6  
and/or autonomous (stateless)
   address configuration.

   to:

   For example, routers can specify whether DHCPv6 services are  
available for address configuration and other
   configuration information.

- Ralph

On Sep 17, 2008, at Sep 17, 2008,11:17 AM, Thomas Narten wrote:

> HYUN WOOK CHA <[email-masked]> writes:
>
>> Hello, Thomas Narten and 6MAN folks.
>
>> I made a presentation for our draft "draft-cha-ipv6-ra-mo-00.txt" at
>> the 6MAN session in Dublin IETF. This draft aims to clarify the
>> handling of the M/O flags of IPv6 RA. Though I got several comments
>> during my presentation, I could not figure out what you really
>> pointed out. So, I decided to ask you again why you think that the
>> issues which the draft addresses are neither clear nor considered as
>> worthy to be discussed in the 6MAN wg.
>
> Meta point. This WG has (multiple times) over the last few years had
> discussions about what the best semantics for the M&O bits should
> be. Despite hundreds of emails, and multiple drafts, there was not
> (and still is not) consensus on what the exact semantics should be.
>
> If you look at the history, RFC 2462 had text about the M&O bits. It
> basically said that if the M or O bit was set, a client should invoke
> DHC. Note: the wording was "should" not "must". When 2462 was reissued
> as RFC4862, all the wording about the M&O bits was removed. The change
> section says:
>
>   o  Removed the text regarding the M and O flags, considering the
>      maturity of implementations and operational experiences.
>      ManagedFlag and OtherConfigFlag were removed accordingly.  (Note
>      that this change does not mean the use of these flags is
>      deprecated.)
>
> This was done because the WG could not agree on alternative wording on
> how to define the M&O bits.
>
> Thus, my main comment at the microphone was that unless something  has
> changed (and I have seen no indication of this), the WG should not
> take on this topic or discuss it further because there is no consensus
> to make any changes.
>
>> First of all, I would like to give a brief summary for the draft.
>
>> Existing specification (RFC2462) does not give a method on how to
>> revoke DHCPv6 clients once they were invoked by the M or O flags of
>> RA messages.
>
> Personally, I do not believe this is wrong or a problem. IMO, it is
> just fine that there is no way to revoke an earlier hint that DHC is
> available and clients should use it. (DHC has its own ways for dealing
> with unresponsive servers -- clients will retransmit at a very low
> rate, in such a way that such retransmissions do not cause operational
> problems.)
>
>> Let us think about the case that a administrator wants to change
>> network policy from stateful addressing via DHCPv6 to stateless
>> one.
>
> It can do so by simply starting to send out RAs with the relevant
> information. There is no need to disable DHC in order to switch to
> stateless configuration. (It would of course be foolish for the
> information sent out via RAs to conflict with the DHC advertised
> information.)
>
>> Although the admin clears M flag of RA messages and reconfigure(or
>> shutdown) the DHCPv6 server, the DHCPv6 clients keep operating. Even
>> after all bindings expire and stateful addresses are invalidated,
>> the client will keep searching another stateful servers by sending
>> SOLICITs, because the DHCPv6 protocol does not care about values of
>> RA flags.
>
> As stated before, I do not consider this to be a problem.
>
>> If the intention of the restriction that DHCPv6 clients should be
>> invoked at the transition from FALSE to TRUE of the M or O flag of
>> RA is that waste of resources of network infrastructure and host
>> devices caused by useless DHCPv6 operation can be prevented and
>> stateful addresses can be configured automatically by the
>> administrative policy, we believe that our draft has value to
>> supplement missing parts which existing specification and
>> implementations have.
>
> Note: there is not WG consensus that if the M/O bits are cleared that
> one MUST NOT invoke DHC. Routers could be misconfigured and leave the
> bits cleared, even though DHC is to be used. Or there may not even be
> a router on the link! Thus, some persons argue that they want the
> freedom to ignore the M&O bits and invoke DHC anyway. That said,
> others (just as strongly) feel that a client MUST NOT invoke DHC if
> the M/O bits are cleared.  This is a point on which the WG simply does
> not have consensus. I do not believe anything has changed in the WG to
> suggest that the WG could reach agreement now, if it were to reopen
> discussion on the matter.
>
>> The second issue (which is likely less important) is concering
>> conflicts M/O flags from different routers which belongs to differnt
>> administrative domains.
>
> This type of environment is problematical and there are no good
> solutions. If two routers are sending out conflicting information
> (intentionally), there is little a client can do to "make things
> right".
>
>> Existing IPv6 stack implementations such as linux are assumed to
>> comply with handling of the M/O flags of RA in the RFC2462. So, they
>> just keep the most recent M/O values without considering senders of
>> RA messages.
>
> In this type of environment, you would presumably want clients to
> continue using DHC even if an RA was received with the M&O bits
> cleared. That is precisely the behavior that is defined/implemented
> today per existing RFCs.
>
> Your proposal would differ and (from what I can tell) cause DHC to be
> enabled/disabled/enabled/disabled/etc/ over and over again. This seems
> like a bad solution in this case.
>
>> This point does not expose serious problems though it does not
>> provide consistent informations about the availability of the DHCPv6
>> service. Since we would like to support revocation of DHCPv6 clients
>> at the transition of M or O flag from TURE to FALSE, the handling of
>> the flags is reworked in our draft to avoid the iteration of
>> invoking and revoking of the clients.
>
> I do not agree with your problem statement that  there is a need to
> revoke DHC.
>
> IMO, the WG should first discuss the actual problem statement. That
> is, discuss what exactly is broken that needs to be fixed. Only if
> there is agreement that we have a problem that needs fixing should the
> WG revisit this topic.
>
> Thomas
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 6 Oct 2008 09:55:59 -0400

Ralph:

How do these changes help the situation?

Why don't we just deprecate the bits????

What value do these bits have if "The DHCPv6 client behavior in response
to the receipt of M and O flags is unspecified."

- Bernie

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Monday, October 06, 2008 9:31 AM
To: Thomas Narten
Cc: Ralph Droms (rdroms); [email-masked]; DHC WG; IPV6 List
Mailing; Bernie Volz (volz); Brzozowski John
Subject: Re: [dhcwg] Request for Advices on the draft
"draft-cha-ipv6-ra-mo-00.txt"

   to:

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Mon, 6 Oct 2008 09:59:07 -0400

Bernie - my suggested clarifications help the situation in that the  
flags are currently underspecified (in fact, IMHO, confusingly  
specific) relative to the previous consensus about their definition.

Deprecating the bits would require a new consensus.

- Ralph

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 6 Oct 2008 10:00:45 -0400

Ralph:

Your changes effectively deprecate them.

- Bernie 

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Monday, October 06, 2008 9:59 AM
To: Bernie Volz (volz)
Cc: Ralph Droms (rdroms); Thomas Narten; [email-masked]; DHC
WG; IPV6 List Mailing; Brzozowski John
Subject: Re: [dhcwg] Request for Advices on the draft
"draft-cha-ipv6-ra-mo-00.txt"

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Mon, 6 Oct 2008 10:03:37 -0400

Bernie - The point of my suggested text is, in fact, to better  
describe the definitions reached in the previous consensus rather than  
make any changes.  In my opinion, the suggested text represents  
clarification and does not make any changes to those definitions.

- Ralph

---

From: "hyunwook cha" <[email-masked]>
Date: Tue, 7 Oct 2008 08:50:23 +0900

<snipped from Ralph's posting>
>>> how will they implement stack behavior for the M/O flags?

Personally I had same questions when I started to implement DHCPv6
clients for our products. Though RFC4861[2] do not specifiy specific
behaviors on client's side, I could refer to existing implementations
like Vista, opensource from IBM, other vendors' web sites and
specification of TAHI conformance testsuit and also, deprectated
RFC2461[2].
IMO, even though more clarifications will be inserted as Ralph
suggested, the situation will be remain same.

If it is correct that M/O bits do not have any values and just results
unnecessary complexity as Thomas, Bernie, and Ted commented, I also
think that new document is necessary to deprecate M/O bits effectively
because current RFCs specify the purpose of M/O bits clearly and sound
to leave usages for M/O bits to implementors' choice temporarily.

However, if current consensus is that the bits are useful and have no
harm, I believe that the issues such as revoking clients and conflict
flags should be addressed clearly.

Joseph

2008/10/6 Ralph Droms <[email-masked]>:
> Bernie - The point of my suggested text is, in fact, to better describe the
> definitions reached in the previous consensus rather than make any changes.
>  In my opinion, the suggested text represents clarification and does not
> make any changes to those definitions.
>
> - Ralph
>

---

From: Thomas Narten <[email-masked]>
Date: Mon, 13 Oct 2008 11:40:27 -0400

OK, I'm going to wade back into this and say that I believe we've
botched things. Let's take a typical client implementor, who looks at,
say, RFCs 4861, 4862 and/or RFC 3315 (the DHCPv6 spec).

Question: just when are they supposed to invoke DHCPv6? All the time?
Only if the M or O bits are set? This simply isn't clearly
defined. This is broken and teh IETF really needs to make a
recommendation. 

Background:

RFC 3315 (the DHCPv6 spec) says:

   IPv6 Stateless Address Autoconfiguration [17] specifies procedures by
   which a node may autoconfigure addresses based on router
   advertisements [13], and the use of a valid lifetime to support
   renumbering of addresses on the Internet.  In addition, the protocol
   interaction by which a node begins stateless or stateful
   autoconfiguration is specified.

But, the two references above point to RFCs 2461 and 2462, which have
been obsoleted. In theory, implementors should be able to look in RFC
4861 and 4862 instead to get the proper guidance.  Unfortunately, they
won't find clear guidance.

RFC 4861 (the ND spec) talks about what to do with the M&O bits, but
only from a router's perspective, i.e., it includes configuration
knobs for setting the bits in outgoing RAs. That is all fine, but
doesn't address what a client implementation should do. The text does
say (in the context of defining the bits):

       M              1-bit "Managed address configuration" flag.  When
                      set, it indicates that addresses are available via
                      Dynamic Host Configuration Protocol [DHCPv6].

                      If the M flag is set, the O flag is redundant and
                      can be ignored because DHCPv6 will return all
                      available configuration information.

       O              1-bit "Other configuration" flag.  When set, it
                      indicates that other configuration information is
                      available via DHCPv6.  Examples of such information
                      are DNS-related information or information on other
                      servers within the network.

But this is very general, and doesn't provide clear guidance to an
implementor.

RFC 4862 is completely silent on what to do. It only says (in the
"changes" section):

This is broken. Implementors should be able to look at the (current)
specifications and get clear advice on what to do. And, are we saying,
in fact, that RFC 2461 has not _really_ been obsoleted and
implementors should look at the older RFCs for guidance? I hope not!

Oh, and the Node Requirements specification isn't much better.
draft-ietf-6man-node-req-bis-01.txt: says:

   6.2.1.  5.2.1.  Managed Address Configuration

   The method by which IPv6 nodes that use DHCP for address assignment
   can obtain IPv6 addresses and other configuration information upon
   receipt of a Router Advertisement with the \'M' flag set is described
   in Section 5.5.3 of RFC 4862.

(RFC 4862 says no such thing actually!)   

   In addition, in the absence of a router, those IPv6 nodes that use
   DHCP for address assignment MUST initiate DHCP to obtain IPv6
   addresses and other configuration information, as described in
   Section 5.5.2 of RFC 4862.  Those IPv6 nodes that do not use DHCP for
   address assignment can ignore the 'M' flag in Router
   Advertisements.

Again, RFC 4862 simply doesn't say the above. It uses "may" language,
and even that is indirect:

   5.5.2.  Absence of Router Advertisements

   Even if a link has no routers, the DHCPv6 service to obtain addresses
   may still be available, and hosts may want to use the service.  From
   the perspective of autoconfiguration, a link has no routers if no
   Router Advertisements are received after having sent a small number
   of Router Solicitations as described in [RFC4861].

So, I think we have made a mess of things and we need to fix things.

I will assert that the fundamental problem we have is that we have not
yet agreed on when a client should invoke DHCP.

Our options are:

1) We could ignore/deprecate the M&O bits and simply have any
   client that implements DHCP invoke DHCP without even bothering to
   see what the M&O flags say. I.e, the way DHCPv4 works today.

   IMO, this approach would work fine. Indeed, it has the advantage
   that the client won't do the wrong thing due to misconfigured
   routers sending out M&O bits with the wrong setting. The main
   downside is that operators would have no way of signalling to
   clients that DHCP isn't available and they shouldn't waste
   resources trying to invoke it. In the past, there has been
   endless(?) debate about how significant the "waste" would be.
     
2) We could restore the M&O bits, and tie DHCP invocation to the
   settings of those bits. This is what 2461/2462 did, and was the
   original model. But, there is still a number of choices to be made
   here:

   a) Treat the M&O bits as SHOULDs, meaning exactly that. If the bits
      are set, one SHOULD invoke DHCP, but it is NOT a MUST
      requirement. If one choses (for whatever reason) not to honor
      the bits, so be it, but it is not a protocol violation per se.

      This is the approach 2462 took, though it used lower case
      shoulds.

   b) Treat the M&O bits as MUST. You MUST invoke DHC if they are set,
      and it is a protocol violation to not do so (if you have
      implemented DHC, i.e., you have a non-complient DHCP
      implementation).

   c) One could also say one MUST NOT invoke DHCP *unless* the M&O
      bits are set.

      Some people/operators wanted such behavior because they wanted a
      way of indicating that no DHCP servers are present, and that
      clients shouldn't waste network resources invoking DHCP (this
      was asserted to be a potential issue on some types of wireless
      WANs).

      Others argued that a robust client would be foolish to rely on
      the proper settings of those M&O bits, as it could lead to
      (unncessary) failures if routers were misconfigured, but DHCP
      servers were available. [this leads back to the call for option
      1) above]

In summary, the current specs are not clear on when a client should
invoke DHCPv6 and when not. That is broken and should be fixed. I also
suspect that it it less important *which* approach we adopt, than that
we do actually choose one and document it.

Thomas

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 13 Oct 2008 18:03:14 +0200

> defined. This is broken and teh IETF really needs to make a

Seems to me that this is simple enough: no bits, no DHCP. "Always" is  
not an acceptable out of the box behavior. (!!!)

Then if there is M you do stateful DHCPv6, if there is O stateless.  
The only problem would be if bot O and M are set.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Alain Durand <[email-masked]>
Date: Mon, 13 Oct 2008 12:12:49 -0400

Thomas,

IPv6 is IPv4 with longer addresses. Why would we want to make life more
complex with more choices wrt starting DHCPv6?

I vote for 1.

  - Alain.

>    see what the M&O flags say. I.e, the way DHCPv4 works today.
[...]
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 13 Oct 2008 18:19:00 +0200

> complex with more choices wrt starting DHCPv6?

That ship sailed when DCHPv6 was invented even though IPv6 works fine  
without it.

> I vote for 1.

This is the IETF; you don't get a vote.

I don't have any use for DHCPv6. I need a way to shut up DHCPv6  
clients that may end up visiting my network. Running DHCPv6 in a  
network that doesn't support is is especially harmful because there  
will be lots of retransmissions, which are multicasts that use up a  
lot of airtime on wifi networks.

So sending DHCPv6 requests with MO = 00 by default is not acceptable.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Thomas Narten <[email-masked]>
Date: Mon, 13 Oct 2008 12:20:05 -0400

> not an acceptable out of the box behavior. (!!!)

In the spirit of keeping this discussion productive and about
engineering, can you please explain why (operationally or technically)
that always is "not acceptable"?

> The only problem would be if bot O and M are set.

There is no problem. You invoke DHCP if either the O or M bits are
set (if the decision is to trigger DHCP invocation on the settings of
the bits).

Thomas

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 13 Oct 2008 18:30:53 +0200

> that always is "not acceptable"?

Ok:

> lot of airtime on wifi networks.

This probably wasn't very clear. What I mean is the situation where  
clients would be initiating DHCPv6 but there are no DHCPv6 servers.  
This is unnecessary multicast traffic that could easily affect wifi  
performance because on 802.11 multicasts are generally sent at the  
lowest supported speed.

Routers have been supporting the setting of the M and O bits for ages  
so it's no trouble setting those if DHCPv6 is desired, so there is no  
real downside to limiting the use of DHCPv6 to the situation where at  
least one of these bits is present in router advertisements from at  
least one router. (It would even be possible to generate RAs with a 0  
lifetime with M/O set for this purpose, hosts won't create a default  
route for those RAs.)

A corner case is the situation where there are no routers, but I don't  
see how having a DHCPv6 server in that case still makes sense (would  
it even work?), communication can and probably should happen over link  
locals in this case.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 13 Oct 2008 09:38:46 -0700

On Mon, Oct 13, 2008 at 06:03:14PM +0200, Iljitsch van Beijnum wrote:
>> Question: just when are they supposed to invoke DHCPv6?

This is essentially Joseph's question (one of them).  He is stating,
"I am an implementer, someone tell me what to do."  He's even willing
to write it down into an RFC so that the answer receives peer review
and hopefully we have a clear and consistent (=interoperable)
solution for other implementers.

>> All the time?
> Seems to me that this is simple enough: no bits, no DHCP. "Always" is not 
> an acceptable out of the box behavior. (!!!)

Why?  It seems perfectly fine to me, since the Solicits follow an
exponential backoff.  Further, it seems pretty clear to me that router
solicitation is on a long path towards deprecation, as it is
incomplete by design, so having DHCPv6 operate by default seems to me
the best way to position current clients for the impending migration.

> Then if there is M you do stateful DHCPv6, if there is O stateless. The 
> only problem would be if bot O and M are set.

The other problem is when there is an A bit.  Does M imply revocation of
A?  Some seem to think so; that A would only be set in this case for
backwards compatibility with clients that lack DHCPv6 stateful support.

The other other problem is when there are two distinct routers, having
two distinct sets of prefixes (each representing a unique
administrative domain, what Joseph understands (rightly?) to be a
valid 'dual homing' setup), of which one, the other, or both are
advertising inconsistent bit values (especially the M&O bits).

The other other other...

There are problems...there are corner cases in the penumbra cast by
these "simple" designs' overlapping reach.  They are not trivial, and
they are almost certainly misunderstood by most.

I like the idea that DHCPv6 should simply always be invoked.  It casts
a clear light, with very little shadow.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 13 Oct 2008 09:49:40 -0700

On Mon, Oct 13, 2008 at 06:30:53PM +0200, Iljitsch van Beijnum wrote:
> A corner case is the situation where there are no routers, but I don't see 
> how having a DHCPv6 server in that case still makes sense (would it even 
> work?), communication can and probably should happen over link locals in 
> this case.

The answer is inconsistent.  Some DHCPv6 clients default to a /64
prefix so that this scenario works, and systems with those clients can
and do interoperate.  The obvious complete solution to this problem is
to deliver the prefix length via DHCPv6, at which point you may as
well also deliver a default gateway, and complete the circle that
starts the deprecation of RA.

Link locals are not sufficient as they are unlikely to appear in DNS.

Welcome to the world of host configuration penumbra; the land of
partial shadows cast by multiple overlapping lightsources and their
obstructions.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 13 Oct 2008 13:24:41 -0400

>and do interoperate.
 
Those clients are broken however. Getting a DHCPv6 address assigned and
assuming it is /64 (and on link) is wrong. If there is no prefix
advertisement, the client should only assume a /128.

I think this behavior came from IPv4 where a host getting an address
without a subnet length assumed the class A/B/C defaults for the subnet
length. In IPv6, that would map to a /64. But that is wrong behavior for
IPv6.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David W. Hankins
Sent: Monday, October 13, 2008 12:50 PM
To: DHC WG
Cc: IPV6 List Mailing
Subject: Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O
bits

> A corner case is the situation where there are no routers, but I don't
see

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 13 Oct 2008 10:42:34 -0700

> advertisement, the client should only assume a /128.

Being "wrong" or "working but broken" in the eyes of the IETF is a
matter that causes few people, including myself, consternation; their
network is working during a router outage.  They don't care if it was
supposed to be broken by design.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 13 Oct 2008 13:47:14 -0400

I'd like to encourage serious and thoughtful conversation about this  
topic.  Thomas is right (I know he's right, because I agree with him)  
that the current text in various RFCs is unclear.  Even if it does not  
conflict with the previous consensus about how to deal with the M/O  
flags, the text does not completely describe that consensus in a way  
that implementors can use to guide development and admins can know  
what to expect from DHCPv6 clients.

This topic was also considered in an earlier thread discussing draft- 
cha-ipv6-ra-mo-00.txt.

The previous consensus about M/O flags, as I understand it, is  
described in the text Thomas quotes form RFC 4861; those flags  
indicate the existence of DHCPv6 service and nothing more.  My  
recollection is that there was no consensus on guidance to hosts about  
what to do with that information from the M/O flags, so (in response  
to Thomas' first question) an implementor is free to build any  
behavior into the DHCPv6 client including "always", "only if M or O  
flag is set", "never".  In my opinion, the existing text needs to be  
extended to completely explain that previous consensus; for example,  
by adding "Note: The DHCPv6 client behavior in response to the receipt  
of M and O flags is unspecified." somewhere in RFC 4861.

It may also be the case that we want to reconsider our previous  
consensus, to give an explicit answer to the question about when to  
run DHCPv6.  draft-cha-ipv6-ra-mo-00.txt gives one possible  
redefinition for those bits.  We have other suggestions ranging from  
"ignore M/O and always run DHCPv6" to "revert to RFC 246[12] and  
disallow DHCPv6 if M/O flags aren't set".  In my opinion, the former  
suggestion sounds perfectly reasonable as a way to simplify the specs  
and the implementations - I have heard it the necessary APIs to get  
the status of M/O flags to a userland DHCPv6 client may not exist in  
some OSes.  The latter makes sense if there is a compelling reason to  
guarantee there is no DHCPv6 traffic on a link.

- Ralph

---

From: <[email-masked]>
Date: Mon, 13 Oct 2008 13:17:38 -0500

Just so I'm clear... when you say "ignore M/O and always run DHCPv6", does that mean stateful or stateless DHCPv6?  And of course, if it is "or", then how is that determined without the M/O bits in the RA?

Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ralph Droms
Sent: Monday, October 13, 2008 1:47 PM
To: Thomas Narten
Cc: DHC WG; IPV6 List Mailing
Subject: Re: Brokenness of specs w.r.t. client behavior with M&O bits

<snip>

- Ralph

</snip>

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 13 Oct 2008 13:39:14 -0700

> Just so I'm clear... when you say "ignore M/O and always run DHCPv6", does that mean stateful or stateless DHCPv6?  And of course, if it is "or", then how is that determined without the M/O bits in…

The general purpose answer is stateful, in terms of being simple to
explain.  But this is really "both."

A DHCPv6 server will answer all Solicits, even if it has no addresses
to provide, with an Advertise.  The difference is in the status code
in each IA.

A client that has obtained, through extra-DHCPv6 means, a global
address and has received Advertises with a status code other than
Success can infer it should enter into stateless operation upon the
conclusion of the current RT counter...there clearly is a DHCPv6
server which it could get configuration from, it just isn't "asking
right".  This is particularly true of clients with fixed manually-
configured IPv6 addresses, they would go straight to stateless.

But there are also contexts of clients that will consider the
downgrade unacceptable, and will continue to Solicit regardless of
Advertise content.

It is, incredibly, contextually dependent.

=== RFC compliance

Note that this suggestion is in stark contast to the current wording
of RFC 3315, which directs that clients MUST ignore Advertises
containing the status code 'NoAddrsAvail', the probable status code in
the downgrade case...except to log them.  I can't remember which
section, but I remember wondering why we bother receiving packets just
to ignore them.  After doing all that work, it seems criminal not to
log the message.  This is later differentiated from the case where the
global status code is Success (or non-present), and a subset of the
client's IA's contain NoAddrsAvail status codes; in this case you do
not ignore the message (but you might not select it).

---

From: <[email-masked]>
Date: Mon, 13 Oct 2008 16:15:32 -0500

>A DHCPv6 server will answer all Solicits, even if it has no addresses to provide, with an Advertise.  The difference is in the status code in each IA.

I don't believe that is an accurate statement.  According to RFC 3736 section 5.1, clients and servers implement the following messages for stateless DHCP service:  Info-Request, Reply, Relay-Forward, and Relay-Reply.

So, there is no Solicit and no Advertise with Stateless DHCPv6.

Greg

---

From: Thomas Narten <[email-masked]>
Date: Mon, 13 Oct 2008 16:59:44 -0400

> clients would be initiating DHCPv6 but there are no DHCPv6 servers.

My understanding is that when clients invoke DHC, and there are no
DHCP servers, they backoff and retransmit, eventually stablizing as is
governed by the following (from RFC 3315):

   MRT specifies an upper bound on the value of RT (disregarding the
   randomization added by the use of RAND).  If MRT has a value of 0,
   there is no upper limit on the value of RT.  Otherwise:

      if (RT > MRT)
         RT = MRT + RAND*MRT

In the case of solicit messages, MRT is set to 120 seconds. RAND is
set to +/- .1, so the RT is capped at between 118 and 122 seconds.

So, clients will retransmit about once every 2 minutes.

> performance because on 802.11 multicasts are generally sent at the  

But let's not forget, Neighbor Discovery also uses IP multicast. So,
if multicasts are problematical they are probably already
problematical just for ND. Right?

Has any analysis been done to show how much *additional* load would be
created by DHCP multicasts above and beyond basic multicast needed for
IPv6?

Finally, can you further explain what you mean by "affect
performance"? If there are no DHCP servers present, it doesn't matter
much if all the clients are sending multicasts using the lowest speed,
since no one is listening. Right?

So, before I'd agree with the notion that the additonal multicast
affects performance in practice, I'd like some explanation/analysis.

> lifetime with M/O set for this purpose, hosts won't create a default  

Did you read my original note carefully? In it, I pointed out that one
concern against trusting the M&O bits was misconfiguration. You may
think this scenario is rare to non-existant, but please acknowledge
that others in the community may view the concern differently than you
-- and indeed, may weigh this concern as more significant than your
concern about additional multicast traffic.

> it even work?), communication can and probably should happen over link  

Sure. In an ad hoc situation, I could set up an DHCP server (and DNS
server) just to serve the local ad-hoc network. No routers present,
just me and my ad hoc friends.

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Mon, 13 Oct 2008 18:07:19 -0400

Greg - RFC 3736 is simply a summary of how DHCPv6 can be used with a  
two-message exchange and a simplified server.  It was intended to  
describe how DHCPv6 might be implemented in network elements to  
provide "other configuration information" without the "overhead" of a  
full-featured DHCPv6 server.  RFC 3736 does *not* describe the only  
way in which a client can get "other configuration information" from a  
server.

If I were doing a client implementation, I would be tempted to key the  
use of DHCPv6 from the availability of addresses and other  
configuration information.  That is, I would guess it would be  
unlikely that a client would use DHCPv6 for address assignment if the  
client has a manually assigned address or a SLAAC address, and I would  
guess the client would use DHCPv6 for other configuration information  
if it doesn't have manually configured information like DNS servers,  
etc.  I would likely set up the DHCPv6 client to send a Solicit if it  
has no other addresses (RA doesn't have 'A' set in prefix advert, no  
manual address) and send an Information-request if it does have  
assigned addresses.

Arguably, this analysis over-simplifies - suppose the host is attached  
to a multi-homed network that uses SLAAC for addresses from one  
upstream network and DHCP for addresses from another.  In that case, I  
suppose the host would have to use both SLAAC and DHCPv6 ... which, I  
suppose, would be OK if the host got the SLAAC prefixes from one  
router and the DHCPv6 prefixes from another.

- Ralph

On Oct 13, 2008, at Oct 13, 2008,5:15 PM, <[email-masked]> wrote:

>> A DHCPv6 server will answer all Solicits, even if it has no  
>> addresses to provide, with an Advertise.  The difference is in the  
>> status code in each IA.
>
> I don't believe that is an accurate statement.  According to RFC  
> 3736 section 5.1, clients and servers implement the following  
> messages for stateless DHCP service:  Info-Request, Reply, Relay- 
> Forward, and Relay-Reply.
>

---

From: Pekka Savola <[email-masked]>
Date: Tue, 14 Oct 2008 07:48:32 +0300 (EEST)

>   endless(?) debate about how significant the "waste" would be.

I don't see why M/O bits would need to be completely deprecated (they 
could still be hints about what should be available in the network).

I've yet to see a DHCPv6 client implementation that would listen to 
the flags in RA and conditionally start or stop the service depending 
of the presence of flags there.  It's more complex to implement and to 
operate reliably. But granted I haven't done an extensive survey; I'd 
be interested in knowing how existing implementations operate.

So I believe we're kidding ourselves if we think the DHCPv6 client 
software writers and operating system SW engineers trying to figure 
out a most reliable way to use DHCPv6 wouldn't start DHCPv6 client 
automatically under every scenario, no matter the flags.  These 
implementations are not going to change no matter what we write in the 
RFCs.

I don't believe the concern about wasting 802.11 airtime or other 
bandwidth is severe enough in those peoples' (or my) mind that it 
would justify the necessary complexity.  There's a lot of other junk 
that hosts spew out anyway (e.g. some won't like similar Bonjour 
multicasts).  If this is truly a problem, we could try to figure out 
solutions for that, e.g. by tweaking the retransmissions or giving 
operational guidance for filtering in switches / access points.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Kadirvel Chockalingam Vanniarajan <[email-masked]>
Date: Tue, 14 Oct 2008 15:10:06 +0800

While we are at this discussion, I need a few clarifications on how the deployments will get impacted. I've put forth my understanding on how things would be. Do correct me if I'm wrong.

1) Is there a way for a IPv6 client to distinguish between a authoritative RA vs non-authoritative RA? I guess not but I may be wrong. I refer to an unauthorized host sending out RA to be non-authoritative RA.

2) In an enterprise-level deployments, IPv6 deployments will typically happen on top of existing subnet segmentation which was driven by IPv4 subnet logistics. If this being the case, expecting RA to be configured by the network administrator on each one of the routers sounds to be a management nightmare.

3) RA-based address assignment is typically meant for scenarios over fewer subnets (like public hotspots/ISPs?) wherein requiring another infrastructure server (like DHCPv6 stateful server) will be a overkill.

Based on the above, it sounds better to NOT have M/O bit to control. They can act as a hint but how well a client can make a decision based on the hint if it cannot say for sure if the RA received is from some authoritative router or not? It would be rather obscure for a client to decide between misconfigured vs an unauthorized host sending RA.

Thanks
Kadir

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 14 Oct 2008 09:48:42 +0200

> So, clients will retransmit about once every 2 minutes.

But they'll transmit packets more frequently initially.

> problematical just for ND. Right?

It's not a question of "problematic yes/no". More multicasts means  
less performance for other stuff. Obviously ARP and ND already  
generate multicasts, as do various discovery systems such as netbios  
and multicast DNS. I believe this is an important reason why 802.11g  
performance in the plenaries during IETF meetings is so bad, but I  
don't have hard figures to support this.

> If there are no DHCP servers present, it doesn't matter

???

The problem is that the multicasts take up large amounts of airtime so  
they get in the way of other traffic; whether someone is listening  
doesn't matter. In the case where there is a DHCPv6 server there will  
be one multicast from the client (I believe the server replies with a  
unicast but I could be mistaken), but in the case where there is no  
server the client will be retransmitting so this means more traffic.

On big wlans this could lead to the perverse situation that people may  
need to run a DHCPv6 server just to get rid of the traffic if there is  
no other way to shut the DHCP clients up. Which there of course is and  
has been for a very long time in the form of the M/O bits.

Implementation difficulties mentioned by others fail to convince me.  
Address configuration is something that needs to be fairly intimate  
with a number of system functions, so if DHCPv6 takes off this will  
undoubtedly happen in the OS like DHCPv4 is usually done today and  
this isn't an issue. Opening a raw socket and listening for RAs is  
also a possibility. It's not like sending out packets with the  
unspecified address is a standard call; DHCP implementations need to  
be close to the network anyway.

> concern about additional multicast traffic.

Where in the community? There was a mention of consensus that DHCPv6  
could/should be initiated always. I certainly don't agree with that  
and don't remember a consensus call about this. If this happened in  
DHC I would argue that the result is invalid because obviously those  
participating there are likely to want to run DHCPv6 and under- 
appreciate the notion of running DHCPv6-less.

I don't see the issue with misconfiguration if the algorithm is to do  
DHCPv6 if there is just one router (or non-router, see my suggestion  
about RAs with zero lifetime) sets one of the bits, even if others  
don't.

We shouldn't turn a potential issue at human timescales into a  
potential issue at packet transmission timescales.

Should anyone misconfigure the bits and DHCPv6 fail to work, this can  
easily be fixed administratively. Should multicasts create a problem  
or DHCPv6 traffic otherwise be problematic then this requires setting  
up filters in the layer 2 infrastructure, which is immensely more  
difficult to do.

Obviously if administrators want to configure their systems to do  
DHCPv6 without the bits present in RAs then they are free to do so.  
What would be bad is that this happens out of the box because there  
are many non-administered or lightly administered networks where it's  
not possible to change this behavior for all hosts that may show up on  
the network.

In other words: if we adhere to the bits everyone can have the  
situation that they want (DHCPv6/no DHCPv6) but if we don't then some  
people will be confronted potentially problematic traffic that they  
have to good way to get rid of.

> just me and my ad hoc friends.

Well if you need to set up two devices then setting up a third (a  
router) doesn't seem like a huge inconvience, so I don't think we  
should make decisions based on this scenario.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 14 Oct 2008 09:54:41 +0200

> Some DHCPv6 clients default to a /64
> to deliver the prefix length via DHCPv6

Right. Not doing that is a flaw in the DHCPv6 design, IMO.

> at which point you may as

Certainly not. The only one who (hopefully!) knows if a router is  
present and functioning is the router itself. Dead neighbor detection  
allows an IPv6 host to switch default gateways if one dies. Moving  
this functionality to DHCPv6 means that this is no longer possible and  
there will be more connectivity issues that must be debugged manually,  
like we have today with DHCPv4.

> Link locals are not sufficient as they are unlikely to appear in DNS.

Works just fine with multicast DNS.

> partial shadows cast by multiple overlapping lightsources and their

I would rather move in the direction where we all implement RFC 5006  
and DHCPv6 is only used to _register_ addresses that hosts select for  
themselves if central knowledge of which host has which address is  
desired.

(Perhaps MO = 11 could indicate this situation, like MO = 10 =  
initiate stateful DHCPv6 for address allocation and MO = 01 = initiate  
stateless DHCPv6 for other configuration.)
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 14 Oct 2008 10:07:43 +0200

On 14 okt 2008, at 9:10, Kadirvel Chockalingam Vanniarajan wrote:

> 1) Is there a way for a IPv6 client to distinguish between a  
> authoritative RA vs non-authoritative RA?

What are those?

> 2) In an enterprise-level deployments, IPv6 deployments will  
> typically happen on top of existing subnet segmentation which was  
> driven by IPv4 subnet logistics. If this being the case, expecting  
> RA to be configured by the network administrator on each one of the  
> routers sounds to be a management nightmare.

They need the routers to send RAs with prefixes that match what the  
DHCPv6 servers will be using to give out addresses from so  
coordination is necessary anyway. At the time these prefixes are set  
up the bits can be set up as well. No additional nightmare.

> how well a client can make a decision based on the hint if it cannot  
> say for sure if the RA received is from some authoritative router or  
> not?

An enterprise already has to handle unauthorized RAs, those are  
harmful in many other ways. (As anyone who received 2002::/16  
addresses during an IETF meeting can attest to.)

But in this case there is no issue if MO != 00 in ONE RA out of the  
RAs sent by all routers means that DHCPv6 will be initiated. So if the  
correct RA goes out it doesn't matter how many additional incorrect  
ones there are.

> of the presence of flags there.

Apart from Vista and special cases such as Cisco routers I'm not aware  
of an integrated DHCPv6 solution; they are all standalone programs  
that run when you run them and don't run otherwise. So there must be  
an administrative decision to run a DHCPv6 client.

> implementations are not going to change no matter what we write in the

Disagree. I've personally seen DHCPv6 struggle to get where it is  
today over the past 5 years. It has been slow going with many mistakes  
along the way. I don't think there is any reason to assume we've  
reached the end state today.

Over time, implementers usually refine their stuff to be more  
compliant. So specifying the correct behavior is a good thing even if  
we don't know for sure implementers are going to turn on a dime and  
implement it overnight.

> would justify the necessary complexity.

There is no complexity. It's just work.

> If this is truly a problem, we could try to figure out
> solutions for that, e.g. by tweaking the retransmissions

THAT would be complexity.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 14 Oct 2008 11:55:06 +0200

> exponential backoff.

See my earlier emails.

> Further, it seems pretty clear to me that router
> solicitation is on a long path towards deprecation,

Where do you see evidence for that? I haven't seen this.

And even if people wanted that, I don't think it's possible to get to  
a situation without RAs from the current situation, where the majority  
of systems _only_ understand RAs, apart from manual configuration.

> as it is incomplete by design

Depends on your requirements. With RFC 5006 RAs provide everything you  
need in an unmanaged / lightly managed network.

> so having DHCPv6 operate by default seems to me

The important thing is that we don't just decide what WE think is best  
but allow everyone to run their networks the way THEY want. Today,  
many people do this without DHCPv6. Presumably, more people will want  
to use DHCPv6 as implementations get better, but I don't see this ever  
reaching 100%.

>> The

> backwards compatibility with clients that lack DHCPv6 stateful  

If you don't have such clients then you can set the A bit to 0 if you  
want DHCP only so this is a reasonable line of thought but do you  
really want to have three different types of hosts on your network:

- stateless autoconfig only
- stateless autoconfig + DHCPv6 (current implementations)
- DHCPv6 only

I'd say specify the desired behavior in a DHCPv6 option.

> advertising inconsistent bit values (especially the M&O bits).

You can have multiple DHCP servers, too.

> they are almost certainly misunderstood by most.

That's why it's necessary that the behavior is simple and predictable  
but still flexible so that something reasonable happens in all cases.

The situation where multiple routers advertise multiple prefixes is  
something that IPv6 supports, and stuff like easy renumbering and  
shim6 even depend on it.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Thomas Narten <[email-masked]>
Date: Tue, 14 Oct 2008 09:11:58 -0400

> But they'll transmit packets more frequently initially.

Sure.

> don't have hard figures to support this.

OK, so I take it your issue boils down to "less multicast is better",
as a general rule.

> doesn't matter.

Can you provide some analysis/data to better define what you mean by
"large amounts of airtime"? Some real numbers would help me put things
in perspective.  And are you talking about Wi-Fi? or some newer, more
exotic WAN technology?

> has been for a very long time in the form of the M/O bits.

Well, this depends on clients adhering to the "MUST NOT" invoke DHC if
the bits are 0. One issue with that is we've heard (in the past) from
client implementors who say they will not adhere to this, because they
cannot have the reliability of their product dependent on the correct
setting of the M&O bits. (I'm not saying I agree with this view, just
repeating a concern that has been raised in the past.)
 
Also, I assume your perspective is from a properly managed (i.e,
enterprise) network where the operators are clueful and have full
control of over the network.

In the past, some folks have expressed the concern that in a home/SOHO
(or less managed) environment, we may have problems with router
products that always leave the bits 0, with no useful way (to
laypeople that is) to configure the setting properly.

> could/should be initiated always.

Please do not put words in my mouth or the mouths of others, it just
adds noise to the discussion. Who has claimed this is a consensus
view? (I certainly have not.)

> I certainly don't agree with that  

Nothing like raising a strawman just to shoot it down...

> easily be fixed administratively.

Not necessarily in a home environment where the operator (grandma) has
little technical clue and/or the $9.99 router doesn't allow one to
properly/easily configure the bits.

> Should multicasts create a problem  

> have to good way to get rid of.

So I take you vote for MUST adherence to the M&O bits. MUST invoke if
set, MUST NOT invoke of 0.

> should make decisions based on this scenario.

Huh? In this ad hoc environment, there is no router available. There
is no magical "third device" lying around available to configure.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Tue, 14 Oct 2008 08:54:54 -0400

"Manfredi, Albert E" <[email-masked]> writes:

> > From: Thomas Narten [mailto:[email-masked]]=20

> >=20
> >=20
> >          RT =3D MRT + RAND*MRT
> >=20
> >=20
> >=20

> This creates a long wait for the user, if his workstation was
> misconfigured to use DHCP when none is available. Seems like a good
> reason to keep the M&O flags, just to avoid that long wait?

You seem to be assuming (incorrectly) that getting addresses via DHC
is a blocking operation, and everything waits 2 minutes until the DHC
step is declared a "failure".  That, of course, would be an awful way
to implement things. Fortunately, the specification doesn't say to do
this. The system invokes DHC, and if/when it provides addresses, they
get configured. Same for stateless address autoconf. Both run in
parallel. No need to block everything for 2 minutes here in the case
there is no DHC server (or no RAs...).

Also, this 2 minute timer is a cap on the maximum value of the
retransmission timer. It is NOT an indication (from a protocol
perspective) that DHC has failed and that the system is supposed to
declare "no DHC servers available". AFAIK, DHC doesn't declare "no
servers available" and then go into any special mode. Rather, it just
continues to retransmit until it gets a response. I.e., until a DHC
server becomes available.

The way DHC & stateless address autonconfiguration are supposed to be
implemented is that both run in parallel and independently of each
other. Whenever one provides addresses, you configure them and start
using them. You don't have to wait for one operatoin to complete
before invoking the other, or anything like that.

Thomas

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 13 Oct 2008 20:15:16 -0400

> From: Thomas Narten [mailto:[email-masked]] 

> concern about additional multicast traffic.

It seems more likely that random clients would be misconfigured, though.

If the M&O flags are misconfigured, then the situation is not much
different from having no flags to begin with. The client would wait some
time before giving up, and using autoconfiguration. But in most cases,
the client can avoid the agonizingly long waits.

Possibly too, a case can be made that the clients' behavior does not
need to be uniquely specified by the IETF. "Use stateful addresses when
they are available" seems like it could be a viable strategy, without
having to incur that long wait to implement it.

Bert

---

From: [email-masked]
Date: Tue, 14 Oct 2008 11:12:49 +0000

"to deliver the prefix length via DHCPv6, at which point you may as
well also deliver a default gateway, and complete the circle that
starts the deprecation of RA."

Agree with the former, not so much the latter.  Regardless of the presence of DHCPv6 infra., not all hosts can / want to do it - thus RAs still needed (and therefore RSs still desirable).

Also - talking about link locals being invalid in this ad-hoc situation is invalid ... There are other (better) ways to do name resolution in that type of situation, even assuming DNS is an option (which is a stretch itself).

/TJ

PS - if anyone is counting, my vote is to do DHCPv6 only when the RA says to(M|O), or in the absence of RAs ... I think that is the "most v6'ish" way to do it while also covering the below-mentioned ad-hoc situations.

Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: "David W. Hankins" <[email-masked]>

Date: Mon, 13 Oct 2008 09:49:40 
To: DHC WG<[email-masked]>
Cc: IPV6 List Mailing<[email-masked]>
Subject: Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O bits

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 14 Oct 2008 09:32:37 -0700

>> Why?  It seems perfectly fine to me, since the Solicits follow an

Why?  They don't answer the question.  If we apply the thinking that
all multicasts must be avoided, then there are a great many protocols
outside of DHCPv6 to which we must also direct our attention.  Your
earlier emails have not convinced me in the slightest.

> Where do you see evidence for that? I haven't seen this.

History.  We had IPv4 ICMP Router Discovery.  It sucked, I remember
it (but it only sucked less than manual configuration, which is what
we had before that).  We had RARP at one time in IPv4 as well.  It
also sucked less than the manual configuration effort, but again it
still managed to suck more than later efforts.  The development of
IPv4 host configuration was a long line of finding answers that
sucked less than their predecessors.

RA, despite its subtle differences, sucks in precisely the same ways.
It fails to suck less than DHCPv4; consequently, anyone who runs dual
stack today uses DHCPv4 to configure IPv6 (using IPv4 nameservers)!

For anyone to see IPv6 seriously as a native (single stack) client
environment, it will have to suck less than or equal to IPv4.  That
won't happen so long as IPv6's framers continue to live in 1985 [1].

There are reasons that IPv4 networks today are built using VRRP
default gateways, and that DHCP is the singly used host configuration
protocol, by a wide margin over others.  It is not because "the
operators just don't understand how cool it would be if they did
everything differently."  It has been a dialogue between IETF
protocols and network operators, and in starting from scratch with
IPv6, the IETF has made the mistake of throwing out the meaningful
results of this dialogue.

> And even if people wanted that, I don't think it's possible to get to a 
> situation without RAs from the current situation, where the majority of 
> systems _only_ understand RAs, apart from manual configuration.

It is true: IPv6 was a protocol born with a silver migration in its
mouth.

My position is that always engaging DHCPv6, despite RA contents, puts
is in a migrate-able position.

> The important thing is that we don't just decide what WE think is best but 
> allow everyone to run their networks the way THEY want. Today, many people 
> do this without DHCPv6. Presumably, more people will want to use DHCPv6 as 
> implementations get better, but I don't see this ever reaching 100%.

I don't see how running DHCPv6 without any RA input keeps anyone from
building the network they want.

Even in IPv4, you are still free to use RARP.

> If you don't have such clients then you can set the A bit to 0 if you want 
> DHCP only so this is a reasonable line of thought but do you really want to 
> have three different types of hosts on your network:

No.  I only want one (precisely one).  All clients should behave
consistently (=compatibly).

> That's why it's necessary that the behavior is simple and predictable but 
> still flexible so that something reasonable happens in all cases.

The error in your reasoning is in thinking that "forked paths will
simplify the network."  It complicates it.  We need a single place to
look for host configuration, not two and certainly not three.  Because
RA's services are a subset of what is made possible with DHCP, it is
appropriate to select the service that fulfills the complete
requirements.  This means either to proceed on a long-path to
deprecate RA and select DHCPv6, or to extend RA to fulfill the
complete requirements (turning it into a DHCPv6-alike in the process),
or to scrap both and create a new single protocol.  These are our real
choices.  I've chosen one which I believe is most expedient: select
DHCPv6.

What is inappropriate, is to contiue to follow a forked path.  Clients
will have to cross-implement along both lines because they can not
dictate into what network they will be thrust.  They have to implement
'all' not 'either/or'.  This is the most severe kind of complication
imagineable.

Light sources cast shadows.  Multiple light sources cast overlapping
shadows; what we call 'penumbra'.  True simplification for host
configuration will come only by reducing the number of sources of
information.

So, I am confident in my position that RA will be deprecated in the
future, and that we should do what we can today to plan for its
absence.

[1] - http://www.youtube.com/watch?v=gVlNIUhHUI8
      There was music still on MTV!
-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Pekka Savola <[email-masked]>
Date: Tue, 14 Oct 2008 19:45:27 +0300 (EEST)

On Tue, 14 Oct 2008, Iljitsch van Beijnum wrote:
> Apart from Vista and special cases such as Cisco routers I'm not aware of an 
> integrated DHCPv6 solution; they are all standalone programs that run when 
> you run them and don't run otherwise. So there must be an administrative 
> decision to run a DHCPv6 client.

Lots of Linux distributions include various DHCPv6 client 
implementations out of the box.  AFAIK none of these include RA 
controls.  DHCPv6 client behaviour is either always enabled or 
manually turned on (when it's always on, regardless of RA contents).

> Disagree. I've personally seen DHCPv6 struggle to get where it is today over 
> the past 5 years. It has been slow going with many mistakes along the way. I 
> don't think there is any reason to assume we've reached the end state today.
>
> Over time, implementers usually refine their stuff to be more compliant. So 
> specifying the correct behavior is a good thing even if we don't know for 
> sure implementers are going to turn on a dime and implement it overnight.

You seem to have a misconception that whatever we write in RFCs has 
any significant bearing with how implementors implement that stuff if 
it doesn't seem to make sense for them.

There are a few rare ones that keep bugging about RA M/O flags 
periodically, the rest just silently ignore them.  And they will very 
likely continue to ignore M/O definitions no matter what we put in the 
spec.

The reality is that most implementors will just ignore anything the 
spec says they don't like or consider unnecessary in the scenarios 
they have in mind.  As long as their code interoperates (in those 
specific scenarios) with other major implementations, most couldn't 
care less.

And in some cases that's a good thing as it gives a hint what's the 
core feature set of the protocol; we can then throw away the rest 
unless there is serious interest in it.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 14 Oct 2008 22:39:34 +0200

On 14 okt 2008, at 22:35, Brian E Carpenter wrote:

>> I would rather move in the direction where we all implement RFC  
>> 5006 and
>> DHCPv6 is only used to _register_ addresses that hosts select for

> How would that work on sites where the IT department policy is to
> pre-assign specific addresses to specific interfaces (i.e. MAC  
> addresses)?
> That is very common practice for IPv4 and I don't see it changing
> on such sites just because of a change of version number.

I realize that this preference on my part isn't going to receive IETF  
consensus so this is a tangent.

But to answer your question: _assigning_ addresses centrally is  
incompatible with SEND and shim6. I'd rather have the latter than the  
former. If hosts register their addresses management is still possible.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Thomas Narten <[email-masked]>
Date: Wed, 15 Oct 2008 08:45:12 -0400

> advertisement, the client should only assume a /128.

Correct, and that is the motivation for
draft-ietf-6man-ipv6-subnet-model-02.txt. See Section 3, for example.

Thomas

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 15 Oct 2008 08:51:05 -0700

> draft-ietf-6man-ipv6-subnet-model-02.txt. See Section 3, for example.

That draft completely misses the original point.  This isn't a
question of whether "ifconfig inet6 2001:db8::1/64" 'should be
permissible' so far as the IETF is concerned.  This is a question
of what the failure model should be when DHCPv6 succeeds but the
link's router(s) are unavailable.

Generally speaking, it is astonishing to the user for the model to
be a complete failure of all communications - not just those to
external nodes.

Consequently, implementations choose to provide a prefix with the
address.

It isn't because "they don't understand the subnet model."  They
understand, and it is broken.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 15 Oct 2008 19:44:33 +0300 (EEST)

On Tue, 14 Oct 2008, David W. Hankins wrote:
> [RA] fails to suck less than DHCPv4; consequently, anyone who runs

I wonder where you have gotten the latter misconception.  There are 
LOTS of networks which *at least in significant parts of their 
network* use manual IPv4 configuration (no DHCP) and 1) manual IPv6 
configuration (both address and default route), 2) manual IPv6 
configuration (only address, default route via RA), or 3) only RA 
(both address and route).

For example, we don't use any DHCP in server-only LANs. (In 'office' 
LANs where laptops, desktops, etc. connect it is used however.)  I'm 
pretty sure this is a very common way to manage servers, though I 
admit that usign DHCP is likely similarly very common.

You seem to underestimate the usefulness of manual configuration, 
especially when coupled with other configuration management tools that 
can help automate it for you.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 15 Oct 2008 10:56:30 -0700

On Wed, Oct 15, 2008 at 07:44:33PM +0300, Pekka Savola wrote:
> For example, we don't use any DHCP in server-only LANs. (In 'office' LANs 
> where laptops, desktops, etc. connect it is used however.)  I'm pretty sure 
> this is a very common way to manage servers, though I admit that usign DHCP 
> is likely similarly very common.

I appreciate this, but it is not universal, partially due to the
varying contexts of 'server'.  I know of administrators who are
charged with the responsibility of presiding over networks that
contain hundreds of Windows servers.

These, they configure with DHCP(v4) and DDNS, offering 3-6 month lease
times.  This automation means the network administrators do not have
to be involved for every construction and deconstruction of a Windows
server within their network.

I would like to intimate that although their HR can put a price tag
on this advantage, reduced helpdesk staff, the DHCP and DNS admins
would not be so ready to suggest you can place a price on this
advantage.

I think it is fair and accurate to say that Unix servers are not
classically configured using DHCPv4, but there are exceptions in large
scale environments (some Beowulfs spring to mind, where often the
nodes are PXE booted).

On this subject...

I firmly believe that automation would be a benefit, if an often
unwelcome one, among even small scale unix server deployments, and
that unix DHCPv4 client implementations have chosen, unnecessarily, to
optimize for laptop environments...requiring to hear from a DHCP
server before using a previously recorded valid lease.  An operation
that is not required per RFC2131, but is optimal in laptop/nomad user
contexts.

This has created a stigma that DHCP in general is inappropriate for
Unix server use, on the basis that the DHCP server must be operational
for any other server to run.  This is an unfortunate fallacy; it is
true of certain DHCPv4 software implementations (ISC's), it is false
of the protocols (both DHCPv4 and DHCPv6).

When speaking of the "IETF DHCP" and not the "ISC DHCP", it is true,
I believe, to say that DHCP automation presents no greater a risk of
"dynamic failure" than the use of ethernet link speed and duplex
negotiation.  No greater downside from involving extra moving parts.

DHCPv6 is even better positioned than DHCPv4 to provide automation
even in small scale server deployments that does not carry DHCPv4's
stigma of unnecessary circular dependency, due to the simplicity and
clear definition of the Confirm message.  I believe ISC's DHCPv6
client is usable for this purpose today, and that all other DHCPv6
clients are similarly capable (so long as they follow RFC3315).

But it is still not universal, as you must also iron out the trust
model of accepting granted configuration; some systems are too
critical to risk spoof attacks (others are just as critical but
reside in a private network), some environments are too weird to
provide adequate filtration.  Manually configuring a key to perform
dynamic configuration diminishes the value of automation.

I'm sure even after (if) we iron this out, it will remain non-
universal.

> You seem to underestimate the usefulness of manual configuration, 

This is probably true.  I also fail to perceive any aesthetic value
to manual configuration; to "having all the bits aligned beautifully
in the config file."  I'm aware these are motivations.

> especially when coupled with other configuration management tools that can 
> help automate it for you.

But this is a contradiction; tools that automate manaul configuration
are not practices that can be described as 'manual'.  It is automated,
it is just reusing the manual interface.  So, you appear to be arguing
over mechanism.  "Some other automation mechanisms suck less for some
purposes."

This, I agree freely; it's not that DHCP(v4/v6) doesn't suck, it's
just that they suck less than some alternatives.

The extent through which the IETF has progressed the discovery of new
(or extended) mechanisms that suck less than their predecessors has
been stunted by IPv6.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 15 Oct 2008 11:03:56 -0700

>> [RA] fails to suck less than DHCPv4; consequently, anyone who runs
missing word: dual
> I wonder where you have gotten the latter misconception.

IETF 71 and previous, where DHCPv4 was used to address client
systems and configure nameservers and domain search paths, while
IPv6 RA was used to give IPv6 addresses.

This is a rare circumstance wherein the IETF network is actually a
fair model of what people really do in networks that are not ad-hoc
nor thrown together at the last minute, excepting the scope of
configuration state.

As an example, it's what we do on our IPv4/v6 dual stack networks.

Sorry for the double post, I noticed this but forgot to include a
reply.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Oct 2008 12:34:20 -0700

> could still be hints about what should be available in the network).

I don't see what good a hint is.   We'd need to understand what advice  
the hint was intending to give.

> be interested in knowing how existing implementations operate.

I actually did write a prototype DHCPv6 client that did this, but it  
was hard, because the DHCPv6 client doesn't have access to the RA  
data.   So it just watches the IP addresses on the interface, and  
behaves according to what it sees.   But your larger point is correct  
- implementing a DHCPv6 client that takes hints or direction from the  
RA requires a degree of integration that is not widely present.

Personally, I feel that the degree of integration required makes  
implementing support for the RA bits a valuable exercise for operating  
system implementors, but I don't think the RFCs should require it.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 15 Oct 2008 15:24:27 -0700

On Thu, Oct 16, 2008 at 11:09:42AM +1300, Brian E Carpenter wrote:
> Two goals, two solutions: that is OK systems engineering IMHO.

Unfortunately (?), the IETF is engaged in protocol engineering, not
systems engineering.  Throwing spaghetti at the wall just to see what
sticks is not adequate protocol engineering.  It is abysmal.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Oct 2008 09:35:08 +1300

On 2008-10-14 20:54, Iljitsch van Beijnum wrote:
...
> I would rather move in the direction where we all implement RFC 5006 and
> themselves if central knowledge of which host has which address is desired.

How would that work on sites where the IT department policy is to
pre-assign specific addresses to specific interfaces (i.e. MAC addresses)?
That is very common practice for IPv4 and I don't see it changing
on such sites just because of a change of version number.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Thu, 16 Oct 2008 07:12:00 +1030

On Tue, 14 Oct 2008 09:48:42 +0200

> don't have hard figures to support this.

Well, that seems to me to be a layer 2 design problem, and so
would be best solved at layer 2, not at layer 3.

The solutions to this problem are well known. Divide the layer 2 domain
up into subdomains, separated by routers, or, if it is necessary to
have a large layer 2 domain, then move to a non-broadcast multiaccess
(NBMA) layer 2 model, and then use NHRP to overcome the lack of layer 2
multicast support. There's even acknowledgement in the NHRP RFC that the
solution could be used in BMA networks:

"Note that while this protocol was developed for use with NBMA
 subnetworks, it is possible, if not likely, that it will be applied
 to BMA subnetworks as well.  However, this usage of NHRP is for
 further study." (RFC2332)

The IETF / lecture hall scenario could probably be fairly easily solved
by having NRHP stacks on the end-nodes, and information in the RAs from
the local routers supplying the NHRP server(s) to use. 

How have the 3GPP people solved this problem? It seems to me to be
quite a similar one. I'd assume they're not allocating out /64s for
each phone to phone tower point to point connection, so that starts to
imply their link layers are NBMA too.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Oct 2008 11:09:42 +1300

David,

On 2008-10-15 05:32, David W. Hankins wrote:
...
>       and in starting from scratch with

As a matter of historical accuracy, the IPv6 auto-config design was
done at a time when DHCP was so new that reliable implementations
were not available. The best model for host auto-configuration
then was probably Appletalk. The initial design goal was very
explicitly to support zero-config router-free stand-alone LANs as
well as routed networks. I don't think there's any reason to abandon
that goal today, even though it's fairly clear that something with
DHCP's level of capability is needed for larger routed networks
that may or may not have a proactive IT manageer.

Clearly, we need precise specification of the interaction
between the two solutions.

    Brian

---

From: Christian Huitema <[email-masked]>
Date: Wed, 15 Oct 2008 15:23:31 -0700

> that may or may not have a proactive IT manageer.

There are at least two other changes in the environment in the last 10 years. First, we have many networks that require authentication (802.1x or variants). Second, we have many networks (wireless) that do not support broadcast very well. If we took these two requirements into account, we would probably end up with something somewhat different from RA, DHCP and SEND.

-- Christian Huitema

---

From: Bob Hinden <[email-masked]>
Date: Wed, 15 Oct 2008 16:30:19 -0700

> then was probably Appletalk.

The IPv6 auto-configuration was modeled after IPX (based on XNS) auto- 
configuration.  IPX was very successful at the time and it's auto- 
configuration mechanisms were considered an improvement over IPv4.  At  
the time considered better for enterprises than IPv4.  The IPv6 auto- 
configuration was based on a protocol that was very widely deployed.

> The initial design goal was very
> that may or may not have a proactive IT manager.

I agree.

Bob

---

From: David Conrad <[email-masked]>
Date: Wed, 15 Oct 2008 18:15:14 -0700

Hi,

On Oct 15, 2008, at 4:30 PM, Bob Hinden wrote:
> The IPv6 auto-configuration was modeled after IPX (based on XNS)  
> auto-configuration.  IPX was very successful at the time and it's  
> auto-configuration mechanisms were considered an improvement over  
> IPv4.  At the time considered better for enterprises than IPv4.  The  
> IPv6 auto-configuration was based on a protocol that was very widely  
> deployed.

Since we're talking about history, one of the things I've always been  
a bit confused about is how stateless auto-config is supposed to work  
with Internet naming (as opposed to Appletalk (and I presume XNS)  
local naming). In a world without DHCP and zero knowledge clients, how  
were names supposed to be associated with nodes?

Thanks,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Oct 2008 15:46:43 +1300

On 2008-10-16 14:15, David Conrad wrote:
> Since we're talking about history, one of the things I've always been a
> bit confused about is how stateless auto-config is supposed to work with
> Internet naming (as opposed to Appletalk (and I presume XNS) local
> naming). In a world without DHCP and zero knowledge clients, how were
> names supposed to be associated with nodes?

I'm not sure there was an answer to that when it was designed. I guess
today we'd argue that DynDNS can be used to register
MyPrinter.MyHouse.MyUserName.example.net, but I'm not too clear about
the trust model.

   Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 16 Oct 2008 15:28:37 +0200

> specific scenarios) with other major implementations, most couldn't  

Not sure what the point of this argument is, unless you mean to say  
that we should all find better things to do with our time than  
participating in the IETF.

If writing a spec is presumed useful it has to be a good spec. The  
IETF writes specifications, not laws, for better or worse.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 16 Oct 2008 16:18:05 +0200

> outside of DHCPv6 to which we must also direct our attention.

Generally people run these protocols because they expect them to do  
something useful. If they knew in advance that the protcol wouldn't do  
anything useful they wouldn't run the protocol. With DHCPv6 we have  
the ability to know in advance that running the client is going to  
achieve results or only waste bandwidth. Telling people to ignore this  
information doesn't make any sense.

Anyone in the cellular industry reading this? What about firing up  
transmitters and using up battery every 120 seconds for a protocol  
that you KNOW isn't going to do anything useful?

> Your earlier emails have not convinced me in the slightest.

I assure you that the feeling is completely mutual.

> RA, despite its subtle differences, sucks in precisely the same ways.

The only time I have trouble with RAs is when there are rogue routers  
on a subnet. But this happens with rogue DHCP (v4) servers as well so  
no difference there.

The good thing about RAs is that my systems always get the same  
address without having to configure stuff and/or have a server keep  
track of leases. RAs also react to changes in addresses or presence of  
routers in a reasonable way, which DHCP can't. RAs also share fate,  
which you can only do with DHCP if the server runs on the router.

So RAs don't suck.

> anyone who runs dual

I can understand they don't use RAs for this because RFC 5006 is  
relatively new, but if DHCPv6 is so great, why would they use the IPv4  
flavor of DHCP??

But what happens today is of no importance in and of itself, as long  
as there is an upgrade path from where we are now to where we need to  
be when regular people start to run IPv6-only.

> protocol, by a wide margin over others.

IPv4 doesn't have and can't have stateless autoconfig. It could have  
RAs for default gateways and dead neighbor detection so VRRP is  
unnecessary, but the current stuff works well enough that it's not  
worth the trouble to try to upgrade the entire IPv4 internet. That  
doesn't mean that a 25 year old protocol with 15 year old extensions  
should be the blueprint for the future.

> It is not because "the

Well, the amount of people that complain that IPv6 changes too much  
seems to be about the same as those that complain that IPv6 doesn't  
change enough so my guess is that they got this more or less right.

For better or worse, IPv6 isn't just IPv4 with larger addresses. You  
can do a lot of things the same as in IPv4, but there are also things  
that you can do with IPv6 that are impossible with IPv4. Or DHCPv6,  
for that matter. For instance, if you want to use SEND, or run shim6  
with uses HBA which is a SEND extension as its security mechanism,  
hosts need to be able to create their own interface identifier. You  
could of course modify DHCPv6 such that a host can create an IID and  
the DHCP server assigns the top 64 bits and then wait 5 years for  
everyone to implement this and a few more years for people to deploy  
and configure it correctly, but this without any trouble with  
stateless autoconfig today so that would only benefit job security and  
nothing else.

(Note that I'm not against _registering_ addresses that hosts create  
using DHCPv6, although it could also be done differently, in  
environments where central knowledge of which host has which address  
is beneficial.)

> is in a migrate-able position.

That doesn't get you closer to a situation where RAs no longer exist,  
which is not a desirable place to be in the first place.

> consistently (=compatibly).

In that case we should deprecate DHCPv6. And also RFC 3041.

IPv6 incorporates all the address configuration mechanisms from IPv4,  
IPX and AppleTalk. We'll have to live with that.

> look for host configuration, not two and certainly not three.

So why isn't there a subnet length field in DHCPv6 address assignment?

Whether you like it or not, the above doesn't decribe IPv6 and  
ditching stateless autoconfig is not a solution, nor is it desirable  
or deployable.

If anything, we should get rid of DHCP. The whole notion that we need  
to specify a binary format for every new piece of data that may need  
to be configured and then wait until both clients and servers are  
updated is completely outdated. A much cleaner approach would be to  
advertise a URL in RAs where hosts can download their configuration  
info in XML format over HTTP. Need an extension? Define it yourself on  
your own servers and clients leveraging the X in XML without having to  
wait for vendors to modify code. I'm sure at some point someone will  
take the time to write down how to do this and it will take the world  
by storm.

> Because
> RA's services are a subset of what is made possible with DHCP,

Yes, and a car is a subset of a plane. Of course if you don't need to  
fly and want fuel economy a car is more useful. What you're arguing is  
that all cars be outfitted with wings because that better fits with  
your world view.

> This means either to proceed on a long-path to

We did this before when we went from ip6.int for the reverse DNS tree  
for IPv6 to ip6.arpa. Even at the very low IPv6 deployment levels at  
that point this must have cost MILLIONS in operational expenses  
without ANY real-world benefit.

The internet isn't your personal playground where you get to change  
stuff just because you don't like it anymore. Changing stuff costs  
money, a tiny bit for vendors and huge amounts for operators. It's not  
yours to spend.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Thu, 16 Oct 2008 10:52:56 -0400

> So why isn't there a subnet length field in DHCPv6 address assignment?

My understanding is (and I would happily have my understanding  
corrected) that there should *never* be a prefix length associated  
with address assignment, whether that address comes from DHCPv6,  
manual address assignment, etc.  Prefix length is not an attribute of  
an address, either an address assigned to an interface or an address  
used for determining packet forwarding; rather, prefix length is an  
attribute of the prefixes in the Prefix List (RFC 4861), as obtained  
from RAs.

The idea of a prefix length associated with an assigned address is a  
carryover from IPv4, as a shorthand for providing prefix information  
to an IPv4 stack.  IPv6 clearly separates assignment of an address to  
an interface from assignment of prefixes to links.

If DHCPv6 were to be extended, a new option for prefix information  
would carry the prefix, length and lifetime information, independent  
of any assigned addresses.

- Ralph

---

From: Pekka Savola <[email-masked]>
Date: Thu, 16 Oct 2008 18:33:20 +0300 (EEST)

On Thu, 16 Oct 2008, Iljitsch van Beijnum wrote:
>> The reality is that most implementors will just ignore anything the spec 
>> says they don't like or consider unnecessary in the scenarios they have in 
>> mind.  As long as their code interoperates (in those specific scenarios) 
>> with other major implementations, most couldn't care less.
>
> Not sure what the point of this argument is, unless you mean to say that we 
> should all find better things to do with our time than participating in the 
> IETF.

The implication of your argument seemed to be that by putting stuff 
we'd like to enforce in the spec would result in vendors implementing 
something they didn't want to implement in the first place.

I was arguing that whatever we put in the spec must have significant 
support in the implementation community, otherwise we'll end up 
creating an irrelevant spec, or even worse, a spec that is contrary to 
deployments out there.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 16 Oct 2008 09:18:49 -0700

> 1) Is there a way for a IPv6 client to distinguish between a authoritative RA vs non-authoritative RA? I guess not but I may be wrong. I refer to an unauthorized host sending out RA to be non-autho…

There isn't.  In DHCPv4 operations, most operators implement link
layer filters, where the potential for nefarious peers on the switch
fabric is possible.  Server-replies come only from servers with these
filters.

A similar method is required with RA, and currently with DHCP (but
some of us think we know how we can put an end to that).  There is a
subtle difference; DHCP filters are just UDP port limitations.  RA
filters have to peer into ND packet fields.

In the balance, this factor makes IPv6 suck equally to IPv4.

> 2) In an enterprise-level deployments, IPv6 deployments will typically happen on top of existing subnet segmentation which was driven by IPv4 subnet logistics. If this being the case, expecting RA…

You are correct.  There are people that configure end-hosts, the
helpdesk, the Unix sysadmins presiding over large clusters, and there
are router operators.  They are, today, organized in different groups
reporting to different directors in most network companies.

These groups don't generally communicate well.  In many companies,
they often share a kind of rivalry.  RA creates a new organization
model where two groups are partially responsible for host
configuration.  I can only imagine what their internal customers
will feel, as each will no doubt point fingers at the other.  The end
result is increased support costs, even if they create new structures
of unified staff.

In the balance, this factor makes IPv6 suck more than IPv4.

> 3) RA-based address assignment is typically meant for scenarios over fewer subnets (like public hotspots/ISPs?) wherein requiring another infrastructure server (like DHCPv6 stateful server) will be…

I think public hotspots/ISPs are out of scope for RA.  The only
environ I can conceive it might be used is in a simple unmanaged dual
stack home or meeting network; where DHCPv4 can cross the bridge to
complete the client's configuration, and where the network is itself
identifying a single home-user, or temporary and so the potential for
abuse is limited.

The simple reason is that even public hotspots or ISPs need to be able
to respond to abuse complaints, or else they will be observed as being
'safe harbors' for criminals, and people will not peer or give them
transit, to reduce their own costs responding to abuse complaints.

This maybe won't be a problem until after blackhats start using IPv6
for attacks.

In the balance, and combined with the lack of DHCPv6 deployment, this
factor makes IPv6 suck more than IPv4.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 16 Oct 2008 14:36:12 -0700

Iljitsch, the last time we discussed this (on nanog@), we argued
technical points until you finished with "I like RA."  I will again
admit freely that I can't (or won't) change what you do or do not
like.  It has never been my intent to adjust your desires.

I think this time you are leading us through an argument in circles,
we have discussed these points overmuch, and so I have no plan to
reply further.

I can agree that we disagree on fundamental principles.

On Thu, Oct 16, 2008 at 04:18:05PM +0200, Iljitsch van Beijnum wrote:
> anything useful they wouldn't run the protocol. With DHCPv6 we have the 
> ability to know in advance that running the client is going to achieve 
> results or only waste bandwidth. Telling people to ignore this information 
> doesn't make any sense.

Here you are wrong; a machine in its cardboard box has no idea what
network it will be thrust into.  Therefore, it must support "all"
potential interpretations of the word 'network'.  Not "one."

> transmitters and using up battery every 120 seconds for a protocol that you 
> KNOW isn't going to do anything useful?

Clearly if a cellphone required DHCPv6 to supply some configuration
parameter, then it would be better for the DHCPv6 server to reply
and fulfill that request.  Governed by timing parameters, the phone
need not transmit (nor receive unsolicited broadcasts) for extended
intervals.

So in this case, disabling RA would be a technical advantage.

> RAs also react to changes in addresses

...identically to DHCPv6 if you weren't aware...

> or presence of routers in a 
> reasonable way, which DHCP can't.

Actually, anyone who has ever used 'routed -q' would object with that
statement.  Providing VRRP-protected exits for clients is a substantial
improvement over ICMP Router Discovery (which is identical to IPV6
RA).

Maybe you could get away with this if your network was 'best effort',
or even 'experimental'.

Anyone trying to make money will not see RA as an acceptable solution.
They may use VRRP, they may use OSPF, but they will not use RA for
router selection.

If for some reason the exits' locators need to change, DHCPv6 can
supply new updated configuration upon every Renew.

> RAs also share fate, which you can only
> do with DHCP if the server runs on the router.

The routers are probably DHCPv6 relays, so you can.  But no one cares
to because VRRP is a better solution than 'routed -q' RA's.

> So RAs don't suck.

Now I know you're lying (or confused).

> new, but if DHCPv6 is so great, why would they use the IPv4 flavor of 
> DHCP??

Let me be clear;

Client systems that support DHCPv6 are configured by it, even at
recent IETF meetings.

Client systems that do not support DHCPv6 (they have gotten drunk on
the RA lemonade) are configured by DHCPv4.

I propose we turn client systems that do not support DHCPv6 into
client systems that do support DHCPv6, and consequently provide an
IPv6 single-stack migration plan.

> But what happens today is of no importance in and of itself, as long as 
> there is an upgrade path from where we are now to where we need to be when 
> regular people start to run IPv6-only.

I agree.  That is my entire goal.

IPv6 has to suck less than or equal to IPv4.

> try to upgrade the entire IPv4 internet. That doesn't mean that a 25 year 
> old protocol with 15 year old extensions should be the blueprint for the 
> future.

Hyperbole doesn't suit you.  I think you will find I agree completely
with your intended statement:

Ancient technology like IPv4 ICMP Router Discovery and reverse-RARP
("DRARP") are unsuitable for modern use.  They were deselected by
IPv4 network operators for technical, not marketing or political,
and still-true-today reasons.

So out with RA, in with DHCPv6.

> Well, the amount of people that complain that IPv6 changes too much seems 
			    ^
		  "on IETF mailing lists"
> to be about the same as those that complain that IPv6 doesn't change enough 
> so my guess is that they got this more or less right.

Fixed it for you.

> For better or worse, IPv6 isn't just IPv4 with larger addresses.

I am a person who doesn't care what IPv6 is, except in the context of
how we transition to what it must be.  I thought I agreed with your
own statement that today's practices are irrelevant except in terms
of transition strategies.  I wonder why you now contradict yourself
in claiming that today's IPv6 is carved in stone for eternity.

> That doesn't get you closer to a situation where RAs no longer exist, which 
> is not a desirable place to be in the first place.

I believe I qualified my technical position in earlier context, and
that this is a summary.  Let me know if you require clarification.

> So why isn't there a subnet length field in DHCPv6 address assignment?

I believe DHCPv6's framers were fooled by false consensus.

> Yes, and a car is a subset of a plane. Of course if you don't need to fly 
> and want fuel economy a car is more useful. What you're arguing is that all 
> cars be outfitted with wings because that better fits with your world view.

I'm not sure if you realized this metaphor is backfiring on you.  I
am proposing that IPv6 clients be presented with a single choice, and
not two, which your metaphor presents.  In short, I'm proposing to
"lop off all the cars' wings".

Physical engineering principles do not directly apply to network
protocol engineering principles.  If you have an argument to make, it
would be better to present it without the crutch of metaphor.

> We did this before when we went from ip6.int for the reverse DNS tree for 
> IPv6 to ip6.arpa. Even at the very low IPv6 deployment levels at that point 
> this must have cost MILLIONS in operational expenses without ANY real-world 
> benefit.

I'm not sure what that has to do with anything, even if it were true.

> The internet isn't your personal playground where you get to change stuff 
> just because you don't like it anymore. Changing stuff costs money, a tiny 
> bit for vendors and huge amounts for operators. It's not yours to spend.

...

Haven't you heard?

DHCP is really "David Hankins Control Protocol."

It's funny because it's true.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 16 Oct 2008 23:48:16 +0200

On 16 okt 2008, at 16:52, Ralph Droms wrote:

> manual address assignment, etc.  Prefix length is not an attribute  
> of an address

Well, that would make sense in an architecture like CLNP where traffic  
between any two hosts initially flows through a router until the  
router sends a redirect, and routers know host addresses through a  
host-router "routeing" protocol (ES-IS).

But in the IP architecture, a system knows which other systems it can  
communicate with directly by virtue of the subnet prefix. For hosts  
you could argue that they can always send packets to a router, so they  
don't really have to know whether an address is directly attached to  
the local subnet. (And in this case redirects are possible with IPv6.)  
But in the IP architecture, there is no difference in this regard  
between hosts and routers, so if other hosts don't know a certain  
address is present on the local subnet, routers also don't know this.

More practically, how do you configure an interface if you don't know  
the subnet mask? Having the address and the subnet mask become  
available separately is very inconvenient in this regard.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 17 Oct 2008 12:51:14 +0200

> we have discussed these points overmuch, and so I have no plan to

It's not a question of who likes what. It's a question of sound  
engineering. Tgere is no excuse for doing something that is  
unnecessary just because you're too lazy to look in the place that  
will tell you whether it's necessary.

If the whole world ends up using DHCPv6 and nobody wants stateless  
autoconfig, I'm sure router vendors will enable the M and O bits by  
default and there is no problem for you, so I don't see why you are so  
pig headed about this issue.

In fact, why don't they just do that today? I'll happily set the bits  
to 0 on my network if that gets rid of the DHCPv6 requests that I  
don't want.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Fri, 17 Oct 2008 06:52:08 -0400

In-line...

On Oct 16, 2008, at Oct 16, 2008,5:48 PM, Iljitsch van Beijnum wrote:

> Well, that would make sense in an architecture like CLNP where  
> traffic between any two hosts initially flows through a router until  
> the router sends a redirect, and routers know host addresses through  
> a host-router "routeing" protocol (ES-IS).

I did not mean to imply anything about requiring IP traffic to be  
forwarded through a router, even initially.  My understanding is that  
the sending node matches the destination address against the Prefix  
List for interface; that Prefix List identifies all the prefixes  
assigned to the link to which the interface is attached.  Each entry  
in the Prefix List has an associated prefix length, which is used to  
limit the bits used in the match.  If the Prefix List entry that  
matches the destination indicates that the destination is on link, the  
node delivers the datagram directly to the destination.

My point is that the Prefix List is logically separate from any  
addresses assigned to an interface.  There may be prefixes in the  
Prefix List from which the node has no addresses assigned to an  
interface, and there may be addresses assigned to the interface that  
are not taken from any prefix in the Prefix List.

The Prefix is (usually) populated through RAs.  Some stacks make an  
assumption that any assigned address must have a corresponding prefix  
on the link.  By associating a prefix length with that assigned  
address, the stack can deduce a prefix, infer that the deduced prefix  
is assigned to the link and add the prefix to the Prefix List.  This

We have already seen one example stack where an address assigned  
through DHCP has caused a corresponding /64 to appear in the Prefix  
List, even though the prefix was not advertised in any RA.  This  
behavior was interpreted as a bug and has been fixed by the vendor.

Extrapolating to DHCPv6, there is no reason for DHCPv6 to assume that  
an assigned address is necessarily taken from a prefix assigned to the  
link.  Address assignment and on-link prefixes are separate and should  
be configured separately through DHCPv6.  We could allow for the  
shorthand, as the usual case will be that the prefix of an assigned  
address will be on-link; an extension might be to use a prefix length  
of 0 to indicate that the address is not taken from an on-link  
prefix.  But, DHCPv6 would still need a mechanism to inform the client  
node about other prefixes from which no addresses have been assigned  
through DHCPv6.  Seems cleaner to me to keep the address assignment  
mechanism separate from the on-link prefix mechanism.  Therefore, my  
strong recommendation would be to leave the DHCPv6 address assignment  
mechanism unchanged and add a new, separate mechanism for informing  
the node about on-link prefixes.

> But in the IP architecture, a system knows which other systems it  
> can communicate with directly by virtue of the subnet prefix. For  
> hosts you could argue that they can always send packets to a router,  
> so they don't really have to know whether an address is directly  
> attached to the local subnet. (And in this case redirects are  
> possible with IPv6.) But in the IP architecture, there is no  
> difference in this regard between hosts and routers, so if other  
> hosts don't know a certain address is present on the local subnet,  
> routers also don't know this.
>
> More practically, how do you configure an interface if you don't  
> know the subnet mask? Having the address and the subnet mask become  

I think many stacks already support the shorthand in which a prefix  
length included with a manual address assignment indicates that the  
prefix derived from the address is assigned to the link.  The problem  
arises when, perhaps through an API, the stack assumes a /64 prefix  
from an assigned address.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Fri, 17 Oct 2008 07:21:34 -0400

I've been tracking this discussion about the M/O flags, which seems to  
be going in several different directions.  I thought it might be  
useful to try to get some agreement on what needs to be done so we can  
focus on coming to consensus on a course of action.  It also seems  
like a small group of participants has gone pretty deep into some  
technical details, which might be irrelevant depending on the  
consensus of the IETF.

Here's a quick, informal survey to assess consensus about how to  
proceed.  Please reply to the list so we can focus our discussion.   
Thanks.

1. Is the following text an accurate summary of the previous IETF
consensus on the definition and use of M/O bits:

   The M/O flags indicate the availability of DHCPv6 service for
   address assignment and other configuration information,
   respectively.  The IPv6 specifications make no requirements on the
   behavior of DHCPv6 clients in response to the values of the M/O
   flags received in RAs.

2. Does the IETF choose to continue to accept this consensus or should
the definition of client behavior in response to the M/O flags be
revisited?

2. YES: Is that consensus adequately described in the IPv6 RFCs or  
should
the IPv6 RFCs be revised in some way to describe the consensus
requirements?

2. NO: How does the IETF want to change this consensus and how should  
the
change process be conducted?

    There have been some suggestions for changes to the current  
consensus
    behavior:

* Deprecate the M/O flags; require that future DHCPv6 clients ignore
   the M/O flags; require that routers send RAs with M/O flags set to 1
* Revert to previous definitions and behaviors in RFC 286*
* draft-cha-ipv6-ra-mo-00.txt

---

From: Ralph Droms <[email-masked]>
Date: Fri, 17 Oct 2008 07:27:55 -0400

Ny own answers, to kick off discussion...

Yes, based on my recollection of the discussion and the text
eventually published in RFC 486[12].

Yes.

The text should be revised to make this consensus clear.

N/A....

   There have been some suggestions for changes to the current consensus
   behavior:

---

From: "TJ" <[email-masked]>
Date: Fri, 17 Oct 2008 09:07:28 -0400

Not trying to oversimplify things here, but to me it makes the most sense to
start with what we have working now and *not* make any broad, sweeping
changes.  To do otherwise is not only a tremendous disservice to all of
those who have implemented/adopted IPv6 (or are considering doing so) but
also fails IMHO to be a good, technical approach to the problem at hand.

I am in no way saying we can't continue adding capabilities (e.g. - XML
config via RA-provided URL) ... but to make drastic changes to functions
that real people are using in real networks to provide real services seems,
well, sub-optimal.

What we have:
	SLAAC
	Stateless DHCPv6
	Stateful DHCPv6
	(Manual Configuration, out of scope for / irrelevant to this
conversation)

SLAAC is well defined, and works quite well - even w/o DNS-option support
being widespread.  Once RFC5006 support is in place, this will be sufficient
for most uses, with a valid concern about the host identification /
(dynamic) name resolution areas.  We can address those, rather than toss the
baby with the bath water.

DHCPv6 is also well defined, with some questions rising around the acillary
pieces - e.g. when does a host run it, and choose which mechanism.  IMHO,
simply making a clearer definition of the M & O bits would be sufficient.

In my world view, the following would be the least painful and most
functional approach:
	Host sends RS
	If RA recevied - look for A/prefix, M, O bits and act accordingly.
		... if one RA specifies one approach, and one RA specifies
the another, do both ...
In almost all properly functioning scenarios this is all the we need, yes?

Additionally ... 
	If no RA received, I am OK with the host making a one-shot attempt
at both stateless and stateful DHCP, just in case
		... the question here - what is the assumed prefix length /
"on link" approach?
			... if we stick with the "right" answer of /128,
well then DHCPv6 didn't accomplish much
				... unless something else comes in to play
						... LLMNR, etc. providing a
hint on onlinkedness, or somesuch.
			... if we assume /64 we raise other problems /
questions
		I think this case is somewhat degenerate and should be rare;
but should nonetheless have a consistent, well defined behavior.

Am I missing anything fundamental here?
/TJ

PS - I totally agree with Iljitsch's "the amount of people that complain
that IPv6 changes too much seems to be about the same as those that complain
that IPv6 doesn't change enough so my guess is that they got this more or
less right" ... I believe another relevant quote would be "rough consensus
and running code".

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 17 Oct 2008 08:31:43 -0700

>the subnet mask?

# ip -6 addr add 2001:DB8::1/128 dev lo

That, along with a few FIB entries, is all the IPv6
configuration some nodes will ever need.

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

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 17 Oct 2008 09:50:32 -0700

>   behavior of DHCPv6 clients in response to the values of the M/O

Yes.  I think it also suffices as a problem statement. :(

> the definition of client behavior in response to the M/O flags be

It's not clear what YES or NO mean in this context.  Yes to the
first and no to the second?  No to the first and yes to the second?

I think you mean by context only the first question.  Someone needs a
lesson in "simple english."

> 2. NO: How does the IETF want to change this consensus and how should the

1) How _should_ it work?
2) How do we migrate?

3) Write it down in an RFC.

>   the M/O flags; require that routers send RAs with M/O flags set to 1

I'm not sure that specifying M/O fixed to 1 is worthwhile, but
generally the deprecation of the flags is the correct direction.

Because I type at 80wpm and can't be stopped:

There is a larger deficit in IPv6 single-stack operations that this
solution puts us on track towards addressing.  That deficit is today
filled in dual-stack networks by DHCPv4.  I am going to continue with
some "next work" items I believe are mandatory for IPv6 single-stack's
adoption;

1) PIO-equivalent information in DHCPv6 replies (even if prefix length
    is simpler for most implementations today).
2) Default gateway configuration in DHCPv6 replies.
3) Deprecation of RA, at the same time:
4) DHCPv6 rapid-commit support (from Solicit to a Reply) which
    includes;
  a) PIO-equivalents.
  b) An indication for the client to commence SLAAC, and transition to
      Information-Request for configuration ("NoAddrsAvail" in any
      IA_NA, or similar (explicit perhaps) mechanism).

This would cause there to exist a single protocol which RA/DHCPv6
should have been from the very start (an equivalent approch is to
extend RS/RA so that RA is identical to a DHCPv6 Advertise, and
additional messages negotiate assigned addresses - I believe selecting
DHCPv6 and backporting SLAAC is more expedient).

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Oct 2008 10:48:32 -0700

> that you KNOW isn't going to do anything useful?

In order for this to be a valid rejoinder, it would have to be the  
case that the cellular industry was planning to use IPv6 autoconf  
combined with RAs to get IPv6 addresses.   It's not my understanding  
that this is the case.   In fact, we added the DHCPv6 rapid commit  
option specifically for low-power applications like the cell phones.

It's true that a low-power device that wants to use a network where  
autoconfiguration is the only option would waste a lot of batteries  
trying to do DHCP.   But it's not required to do so.   I would expect  
the implementation to take into account the circumstances under which  
it was being used.

> which you can only do with DHCP if the server runs on the router.

I actually agree with your conclusion that RAs don't suck, but I will  
point out one flaw in your reasoning here.  RAs follow a push model.    
A server sends out an RA, and recipients are expected to change their  
network configuration on that basis.   DHCP follows a handshake model,  
where the client asks a question, and the server answers it.

In the push model, if you have no pre-established authentication,  
anybody can push out a new network configuration change, and if it's a  
bad configuration, your network is dead until you can track down the  
miscreant and disconnect it.   In the handshake model, there are very  
restricted circumstances under which you can change the configuration  
of the client - only when the client asks you a question can you give  
a wrong answer.   And in doing so you are competing with the  
legitimate answer, and the client will typically see both answers and  
prefer the same answer it heard before.

So a network that uses DHCP for configuration will be much harder to  
DoS.   And more to the point of your reasoning, DHCP and RA do not  
share the equivalence that you claim they share in the first  
paragraph.   The behavior of a rogue DHCP server is very different  
than the behavior of a rogue RA server.

> should be the blueprint for the future.

Actually, there is Bonjour, which works quite nicely for stateless  
IPv4 address configuration.   And we used to use RIP on IPv4  
networks.   RIP is a lot like RA.   I haven't seen RIP in use anywhere  
in a long time - not since the mid-nineties.   Why not?   DHCPv4 is  
preferable.   By preferable, I mean that that's what everybody's  
chosen to use, even though they are free to use RIP.   I don't mean  
"hypothetically better."

Whether the same relationship holds with RAs and DHCPv6, I couldn't say.

Bob Hinden pointed out that RAs are modeled after IPX.   I find this  
observation quite interesting - I used to work at a bank where we had  
large networks with IPX.   The network was virtually unusable half the  
time because of the wild packet storms that would occur due to IPX  
broadcast traffic.   I don't mean to say that a network operated with  
RAs would have the same characteristics, but the fact that IPX was  
widely used in corporate environments in the nineties is not a reason  
to consider it a good model.   IPX has been almost completely replaced  
by IPv4.   Why?   We could speculate that it's because it works  
better, but we don't really need to do that.   The market has spoken.

> So why isn't there a subnet length field in DHCPv6 address assignment?

Because every time it comes up, non-DHC people say "just use router  
advertisements to figure out the prefix length."

> The whole notion that we need
> updated is completely outdated.

Updating an XML schema every time you get a new option is no different  
than updating a server configuration or client configuration to  
understand a new option.   Most existing DHCP clients and servers are  
able to be so updated by the user, without any requirement for a  
software update, just as would be the case with XML/HTTP.

> money, a tiny bit for vendors and huge amounts for operators. It's not

That's right.   But we are discussing a real problem here, not a  
hypothetical problem.   We need to solve the real problem.   All these  
digressions on which protocol is better are fascinating, but not to  
the point, unless the solution is to deprecate one protocol or the  
other, which I think is unlikely.

So we need to come up with some actual guidance as to what  
implementors should do.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Oct 2008 13:03:51 -0700

>   behavior of DHCPv6 clients in response to the values of the M/O

It seems like it is, yes.

> the definition of client behavior in response to the M/O flags be

I think the current spec is vague, and therefore harmful to  
interoperability.   So I'd like the IETF to consider changing it.

>   the M/O flags; require that routers send RAs with M/O flags set to 1

This would be my preference.

> * Revert to previous definitions and behaviors in RFC 286*

I think this is a bad idea, but if the consensus is to go this way  
then we need to tweak what is said in the old RFCs, because what they  
said still wasn't very helpful.

> * draft-cha-ipv6-ra-mo-00.txt

I think this draft nicely summarizes the problem, but that the  
proposed solution isn't ready for prime time.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 17 Oct 2008 16:32:36 -0400

The failure model in the absense of the link's router(s) are described
in RFC 4943.

In particular, the assumption that all hosts are on-link in the absence
of RA's was deprecated.

Whether there is something more useful that can be done in this case is
future work that the IETF may or may not take on.

- Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David W. Hankins
Sent: Wednesday, October 15, 2008 11:51 AM
To: DHC WG
Cc: IPV6 List Mailing
Subject: Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O
bits

> draft-ietf-6man-ipv6-subnet-model-02.txt. See Section 3, for example.

That draft completely misses the original point.  This isn't a question
of whether "ifconfig inet6 2001:db8::1/64" 'should be permissible' so
far as the IETF is concerned.  This is a question of what the failure
model should be when DHCPv6 succeeds but the link's router(s) are
unavailable.

Generally speaking, it is astonishing to the user for the model to be a
complete failure of all communications - not just those to external
nodes.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 17 Oct 2008 16:54:55 -0400

Ralph:

Let's review where the consensus stands (though I'm not sure how much
"past" history I'm including here and that may alter my preception of
what I think this consenus means).

A way that this could be restated as:

	If the M flag is set, a DHCPv6 client MAY run (stateful) DHCPv6.
	If the O flag is set, a DHCPv6 client MAY run (stateless)
DHCPv6.
	A (statless/stateful) DHCPv6 client MAY run regardless of the
state of the M/O flags.

Thus, from a newtwork administrator's view:

If a network is using stateful DHCPv6, set the M (and O) flags.
If a network is using stateless DHCPv6, set just the O flag.
If a network is not running DHCPv6, don't set either of the flags.

In all cases, what actually happens on the network with respect to
DHCPv6 is indeterminate.

The RFC 2462 text was technically just as unspecific:

                                                      Router
   Advertisements contain two flags indicating what type of stateful
   autoconfiguration (if any) should be performed. A "managed address
   configuration" flag indicates whether hosts should use stateful
   autoconfiguration to obtain addresses. An "other stateful
   configuration" flag indicates whether hosts should use stateful
   autoconfiguration to obtain additional information (excluding
   addresses).

And, later:

   On receipt of a valid Router Advertisement (as defined in
   [DISCOVERY]), a host copies the value of the advertisement's M bit
   into ManagedFlag. If the value of ManagedFlag changes from FALSE to
   TRUE, and the host is not already running the stateful address
   autoconfiguration protocol, the host should invoke the stateful
   address autoconfiguration protocol, requesting both address
   information and other information.  If the value of the ManagedFlag
   changes from TRUE to FALSE, the host should continue running the
   stateful address autoconfiguration, i.e., the change in the value of
   the ManagedFlag has no effect.  If the value of the flag stays
   unchanged, no special action takes place. In particular, a host MUST
   NOT reinvoke stateful address configuration if it is already
   participating in the stateful protocol as a result of an earlier
   advertisement.

There are "should" statements, not SHOULD. (RFC 2462 used RFC 2119
terminology in plenty of other places.)

So the existing IETF consensus is really no different than was stated in
RFC 2462 (though in a lot less words). I think it changed a "should" to
"may", but that's not the same as changing a SHOULD to a MAY.

However, it is interesting that RFC 2462 also stated:

   If a link has no routers, a host MUST attempt to use stateful
   autoconfiguration to obtain addresses and other configuration
   information. An implementation MAY provide a way to disable the
   invocation of stateful autoconfiguration in this case, but the
   default SHOULD be enabled.  From the perspective of
   autoconfiguration, a link has no routers if no Router Advertisements
   are received after having sent a small number of Router Solicitations
   as described in [DISCOVERY].

This seems to be major change in RFC 4862 as it provides a "may" in this
case:

Thus, my answers to your questions ...

1 is YES.

While in many ways I'd prefer to deprecate the bits (they've caused so
much debate), after the debate and working to put this email together, I
think the consensus is fine.

2 is a YES, but whether to clarify the existing text is in my mind the
key question. Just the fact that we're having this debate I think says a
lot about the need to clarify this. I think the issue with the existing
wording is that it requires a lot more thought than I think it should
(such as reading through this lengthy debate). There's no easy answer
for network administrators as to how they need to set the bits and for
client implementers on whether they should or should not pay attention
to them. And, clearly the bits are NOT deprecated.

In my view, I believe encouraging implementers to use the M & O bits is
a good thing (the RFC 2462 "should") but a client's local policy should
be able to override that (always on, never on, or "use M&O" if
possible). What client vendors ship the default as is up to them as it
depends on the target customer/market. I also understand that there are
complexities around integrating M/O clear to set transitions in many
stacks or even finding out the state of these bits on an interface.

I fear without this encouragement that the bits would eventually become
completely useless and thus effectively deprecated. (It is a lot easier
just to have a two way toggle - run or don't.) Thus, if we DON'T want to
add clarifications somewhere (new I-D?), I think we should just move to
deprecate the bits.

Finally, this consensus does not prevent additional work, such as
draft-cha-ipv6-ra-mo-00.txt, though obviously that work can't impose any
requirements (MAY/SHOULD/MUST) on implementations to use the M/O bits -
it can give guidance on what a DHCPv6 client that does use the bits may
want to do if the flags transition in certain ways. Whether clients
implement that is up to them (as is whether they pay any attention to
the M/O bits in the first place). Perhaps this work should just be
extended or reframed to provide the motivations for DHCPv6 clients to
use the bits.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ralph Droms (rdroms)
Sent: Friday, October 17, 2008 7:22 AM
To: IPV6 List Mailing; DHC WG
Subject: Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O
bits

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 17 Oct 2008 17:31:54 -0700

At Wed, 15 Oct 2008 08:51:05 -0700,

> link's router(s) are unavailable.

(It's questionable to me whether such a situation is practically so
useful that it warrants, e.g, introducing a new DHCPv6 option, but
aside from that point,)

In this case, the DHCPv6 server (or a relay, which would also rely on
a router and wouldn't work in this situation anyway) can send out an
RA with the router lifetime being 0 and with a prefix information
option.  The server could actually keep sending such minimum RA,
whether or not other routers are active.

If the possible alternative were to introduce a new DHCPv6 option that
includes this information, we should be able to assume the server (as
a node) is configured with that information, so it's just a matter of
which function is implemented in that node.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 17 Oct 2008 20:02:17 -0700

At Tue, 14 Oct 2008 07:48:32 +0300 (EEST),

> be interested in knowing how existing implementations operate.

Just FYI, KAME's "router solicitation daemon" has an ability to invoke
a specified program (which is expected to be a DHCPv6 client) when it
sees the O flag of RA change from false to true.  It's incorporated
into (at least) FreeBSD.  It doesn't support the M flag, though.

I generally agree with your other points, specifically,

- implementors will tend to ignore these flags even if a new spec
  prohibits DHCPv6 invocation more strongly when M/O bits because that
  *may* help if a DHCPv6 server happens to be there (they'd rather
  avoid the situation where configuration fails simply because the M/O
  bits are off)
- 802.11 airtime issue is not convincing enough, at least without
  concrete numbers to prove its severity, to discourage such tendency
  of implementors.

---
JINMEI, Tatuya

---

From: "TJ" <[email-masked]>
Date: Sat, 18 Oct 2008 12:54:44 -0400

"an equivalent approach is to extend RS/RA ..."
Just FWIW - IMHO that would be better than the deprecation of RAs.

(Although I personally am OK with both RAs and DHCPv6 ... I think we just
could use a cleaner definition of the M & O bits and how the hosts act on
them)

/TJ

>Sent: Friday, October 17, 2008 12:51 PM
>To: DHC WG
>Cc: IPV6 List Mailing
>It's not clear what YES or NO mean in this context.  Yes to the first and
no
>to the second?  No to the first and yes to the second?
>
lesson
>in "simple english."
>> the change process be conducted?
>
>1) How _should_ it work?
>2) How do we migrate?
>
>I'm not sure that specifying M/O fixed to 1 is worthwhile, but generally
the
>deprecation of the flags is the correct direction.
>
>
solution
>puts us on track towards addressing.  That deficit is today filled in dual-
>stack networks by DHCPv4.  I am going to continue with some "next work"
>items I believe are mandatory for IPv6 single-stack's adoption;
>
>This would cause there to exist a single protocol which RA/DHCPv6 should
>have been from the very start (an equivalent approch is to extend RS/RA so
>that RA is identical to a DHCPv6 Advertise, and additional messages
>negotiate assigned addresses - I believe selecting

---

From: Kadirvel Chockalingam Vanniarajan <[email-masked]>
Date: Sun, 19 Oct 2008 12:48:59 +0800

Based on the discussion I have seen so far, having support for both is ok for desktop kind of machines which hardly move out of premise but with the advent of nomadic devices, I feel this is going to make it difficult for the clients to make the right choice safely.

1) What could be the scenario wherein M=0 and O=1 will be useful from deployment standpoint?

2) Static address assignment, RA-based assignment and DHCPv6 are three different ways to provision addresses to clients. Static and the other two are contrary to each other. But can a client handle both RA-based as well as DHCPv6 based address assignment? Though it may not be a viable scenario, it will most likely occur for various reasons - misconfiguration, unauthorized servers and what not. In such a scenario how can the client reliably choose the address and settings (like DNS servers) and be able to function properly.

3) If home scenario is really what RAs will be most useful for, RAs can straightaway assign prefixes rather than having M/O bits. On the contrary, these(CPE) are the devices for which recommendation should be carefully made as any revision of proposal is going to cause lot of interop pain.

4) If RAs are deemed to be useful for non-home scenarios as well, securing against attacks should be done for both RA as well as DHCPv6 which might be a significant problem for clients to be solved. This could be a reason to go with one way rather than both.

Both DHCP and RA play a crucial role as they both occur before network discovery. So it would be significantly harder for clients to decide whether they are on a network to allow RAs or not. For managed clients, it's the administrators nightmare. Of course, had it been wireless networks it can be associated with SSID and managed but even otherwise, it is going to involve some bootstrapping/provisioning issues. From network administrators point of view, in non-home network scenario, DHCPv6 might seem more appropriate but given that a client may not know what to expect out of the network, it would have to understand both

5) I'm not sure if it has happened in the past or not. But perhaps since this group comprises the significant portion of the technical community, it would perhaps help to put out some deployment guidelines as well which would help implementers to choose the right model to support the technology.

Thanks
Kadir

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Oct 2008 09:13:20 +1300

> filters have to peer into ND packet fields.

Have you reviewed draft-chown-v6ops-rogue-ra-01? Does it state
the issues correctly? (Please reply to v6ops, not here.)

    Brian

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Fri, 17 Oct 2008 10:20:04 -0400

I have been lurking on this discussion for a while and have one
observation.  Regardless of the values of the M&O bits or the prefixes
(and their lengths) that are advertised, I suggest that the client not
send any messages until it receives a "General Query (RFC 3810)."   If
the client does not hear a GQ within a suitable time (either TBD or
SOL_TIMEOUT, etc per RFC 3315), I suggest that the client "assumes"
that no DHCPv6 server is available.  This goes a short way to
preventing the simplest RA (here meaning router advertisement, NOT
relay agent) spoofing.

Thoughts?

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
TJ
Sent: Friday, October 17, 2008 9:07 AM
To: 'IPV6 List Mailing'
Cc: 'DHC WG'
Subject: RE: [dhcwg] Brokenness of specs w.r.t. client behavior with
M&O bits

Not trying to oversimplify things here, but to me it makes the most
sense to
start with what we have working now and *not* make any broad, sweeping
changes.  To do otherwise is not only a tremendous disservice to all of
those who have implemented/adopted IPv6 (or are considering doing so)
but
also fails IMHO to be a good, technical approach to the problem at
hand.

I am in no way saying we can't continue adding capabilities (e.g. - XML
config via RA-provided URL) ... but to make drastic changes to
functions
that real people are using in real networks to provide real services
seems,
well, sub-optimal.

What we have:
	SLAAC
	Stateless DHCPv6
	Stateful DHCPv6

SLAAC is well defined, and works quite well - even w/o DNS-option
support
being widespread.  Once RFC5006 support is in place, this will be
sufficient
for most uses, with a valid concern about the host identification /
(dynamic) name resolution areas.  We can address those, rather than
toss the
baby with the bath water.

DHCPv6 is also well defined, with some questions rising around the
acillary
pieces - e.g. when does a host run it, and choose which mechanism.
IMHO,
simply making a clearer definition of the M & O bits would be
sufficient.

In my world view, the following would be the least painful and most
functional approach:
	Host sends RS
	If RA recevied - look for A/prefix, M, O bits and act
accordingly.
		... if one RA specifies one approach, and one RA
specifies
the another, do both ...
In almost all properly functioning scenarios this is all the we need,
yes?

Additionally ... 
	If no RA received, I am OK with the host making a one-shot
attempt
at both stateless and stateful DHCP, just in case
		... the question here - what is the assumed prefix
length /
"on link" approach?
			... if we stick with the "right" answer of
/128,
well then DHCPv6 didn't accomplish much
				... unless something else comes in to
play
						... LLMNR, etc.
providing a
hint on onlinkedness, or somesuch.
			... if we assume /64 we raise other problems /
questions
		I think this case is somewhat degenerate and should be
rare;
but should nonetheless have a consistent, well defined behavior.

PS - I totally agree with Iljitsch's "the amount of people that
complain
that IPv6 changes too much seems to be about the same as those that
complain
that IPv6 doesn't change enough so my guess is that they got this more
or
less right" ... I believe another relevant quote would be "rough
consensus
and running code".

---

From: Markku Savela <[email-masked]>
Date: Fri, 17 Oct 2008 14:48:56 +0300

> From: Ralph Droms <[email-masked]>

>    behavior of DHCPv6 clients in response to the values of the M/O

YES.

> the IPv6 RFCs be revised in some way to describe the consensus

YES.

I don't know how to fix the descriptions, for example a host prepared
to support multihoming, would

 - configure addresses from RA, and

 - if it sees M/O, it might *also* try to acquire additional addresses
   from DCHPv6

 - if also might acquire IPv4 addresses via DCHPv4, and get the DNS
   servers from it (to be used for both IPv4 and IPv6 resolutions)

Or a host might wait for RA, and see if M/O are set. Depending on some
local configuragtion toggle in the host, it could either prefer DHCPv6
or RA address configuration.

Or based on some configuration toggle on a host, it could just do
DHCPv6 without waiting RA.

Or, etc...

There are many possible needs for the host, I don't think IETF should
limit the possible actions by a too restrictive specification.

ps. I still think that the RA could also include DNS server addresses
(as proposed by some RFC? Draft?)
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 20 Oct 2008 09:18:00 -0700

> whether or not other routers are active.

As my own peculiar brand of server implementer, this means a few
things that I would wind up doing (can't speak for other
implementors);

I would have to implement at least the RA message, and probably also
reception of RS messages, within my DHCPv6 server software (so as to
ease and correct administrator configuration).

I would, in order to ensure the offered configuration was usable at
the moment it was delivered, and unable to sense the presence or
absence of prefix configuration within the client, have to follow
every DHCPv6 Reply with an RA (with maybe some optimization later).

When I look at it that way, again as my own personal breed of DHCPv6
server implementor, it is far easier for me to adopt a new
configuration option now (at a time when DHCPv6 deployment is still
beginning and malleable), than it is to implement a great deal more
software.

It's the difference between one line in a table of option formats
in our software, and whole sections of new code, more sockets to
open, maintain, etc.

As my own peculiar brand of client implementer, this also means at
least one thing that I would wind up doing.  In this case, we cannot
predict that other server implementors will offer RA (it certainly is
not stated in RFC 3315).  So I would still default to /64 sized subnet
masks.  I have not made up my mind on whether I would have to
implement router solicitation in the client, or what I would have the
client do when it reached a bound sate without prefix configuration.

It is my opinion that when you take the long view in maintenance of
these protocols and networks, the only easy way out is to provide a
single configuration protocol.  It is a vast DHCPv6 client
simplification to obsolete RA, and run the client upon interface
initialization.  Much more of a gain than the extra implementation
in new options (which are just a few entries in a table and some
shell scripting).

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 22 Oct 2008 09:26:57 -0700

Just a few things that I think are potential factual errors or
misreads that need clarifying.

On Tue, Oct 14, 2008 at 09:48:42AM +0200, Iljitsch van Beijnum wrote:
> It's not a question of "problematic yes/no". More multicasts means less 
> performance for other stuff. Obviously ARP and ND already generate 
> multicasts, as do various discovery systems such as netbios and multicast 
> DNS.

Note that if you're concerned about Multicasts, a DHCPv6 client in
steady-state will, at the server's will, unicast its renewal messages
as well as receive unicast replies.  DHCPv6 only requires multicast
to locate DHCPv6 servers.  Once located, the servers may express
their will to receive further unicasts.

DHCPv6 clients are not required to perform DAD, as the address is
assigned by a central authority and the potential for conflict is
very low.  So no spurious ND multicasts.

In the final analysis, there's far less required multicasts in a
DHCPv6-only design overall.

> Which there of course is and has been for 
> a very long time in the form of the M/O bits.

This is potentially a factual misrepresentation depending on how you
read it; it could imply that on today's networks you can reliably
disable DHCPv6 client transmission by clearing the bits.

The truth as I am given to understand it is that client implementation
of the bits vary, in ways that can only be described as independent
and incompatible interpretations of IETF RFC's at best ("totally
broken" at worst).

Clearing the bits is not reliable among all DHCPv6 client
implementations.  It is not a tool anyone can realistically
believe they possess today.

> Opening a raw socket and listening for RAs is also a possibility. It's not 
> like sending out packets with the unspecified address is a standard call; 
> DHCP implementations need to be close to the network anyway.

DHCPv6 has no such requirement thanks to link-local addressing.  ISC's
DHCPv6 software suite uses standard sockets, no raw sockets.  The
server and relay just have additional system calls to join the
appropriate multicast memberships.

Our DHCPv6 software has very little knowledge of the host OS's network
related software.  Configuration is managed via shell-scripts written
by the system integrator (so no kernel methods are required to set
addresses on an interface, for example).  Our software does poll
standard API's for MAC addresses to assign a DUID-LLT if one hadn't
been generated already; but even this is not a hard requirement of the
protocol, merely an implementation choice we made.  The client is free
to allocate a DUID-EN, which need not be based on anything from the
host OS's network stack.

So, no such "closeness to the network" exists today, and I would
resist creating any.  We found many DHCPv4 client implementations
that were notoriously distant from the host's network related
systems (unable to determine its own IPv4 addresses, unaware of which
'interface' might be used, and certainly incapable of determining its
MAC address, all of which leads to some very strange looking DHCPv4
packets), which suggests creating new forms of closeness is not
desirable for the long-term welfare of the protocol.

---

From: "hyunwook cha" <[email-masked]>
Date: Thu, 23 Oct 2008 08:59:03 +0900

Hello, Ralph and all.

I would like to insert another option into the following list.
draft-ietf-ipv6-ra-mo-flags-01.txt
I am not clear why this WG document failed to proceed. However, I view
this document as nice base docuement since I think that it seems that
we do not have clear reason to deprecate M&O bits and it is more
desirable to let host's local policy override M&O bits in received RA.

One thing I would like to point is that our draft
"draft-cha-ipv6-ra-mo-00.txt" just aims to clarify old
specifications(RFC2461/2462) and provide better guidance to
implementors. So, I would say that our draft can be merged with
"draft-ietf-ipv6-ra-mo-flags-01.txt" or extended to contain the whole
framework w.r.t processing the bits.

Joseph

2008/10/17 Ralph Droms <[email-masked]>:
> I've been tracking this discussion about the M/O flags, which seems to be
> going in several different directions.  I thought it might be useful to try
> to get some agreement on what needs to be done so we can focus on coming to
> consensus on a course of action.  It also seems like a small group of
> participants has gone pretty deep into some technical details, which might
> be irrelevant depending on the consensus of the IETF.
>
> Here's a quick, informal survey to assess consensus about how to proceed.
>  Please reply to the list so we can focus our discussion.  Thanks.
>
> 2. YES: Is that consensus adequately described in the IPv6 RFCs or should

---

From: <[email-masked]>
Date: Thu, 23 Oct 2008 13:37:08 +0300

Hi,

Used link-layer does have an impact: on cellular networks the link-layer is nowadays most often opened on-demand (i.e. when an application starts), or quickly reopened e.g. if network connection is temporarily lost for any reason. In the future always-on connectivity becomes more commonplace than it is today, but temporal connection failures may remain in game.. So, when a connection is (re-)opened, IPv6 address needs to be obtained as quickly as possibly for the reasons of good user experience (user is waiting for something to happen..). Often the connection is trusted point-to-point connection, so there is no risk of spoofed RAs. As user is waiting, there is no time to start guessing whether DHCP is available or not, but address will be configured by fastest means available - currently by sending RS immediately when link layer gets up to ensure fastest possible retrieval of RA.

Best regards,

	Teemu

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Dunn, Jeffrey H.
>Sent: 17 October, 2008 17:20
>To: TJ; IPV6 List Mailing
>Cc: DHC WG; Dunn, Jeffrey H.
>I have been lurking on this discussion for a while and have 
>one observation.  Regardless of the values of the M&O bits or 
>the prefixes (and their lengths) that are advertised, I 
>suggest that the client not
>the client does not hear a GQ within a suitable time (either 
>TBD or SOL_TIMEOUT, etc per RFC 3315), I suggest that the 
>client "assumes"
>preventing the simplest RA (here meaning router advertisement, 
>NOT relay agent) spoofing.
>
>Thoughts?
>
>Best Regards, 
>  
>Jeffrey Dunn
>Info Systems Eng., Lead
>MITRE Corporation.
>(301) 448-6965 (mobile)
>
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of TJ
>Subject: RE: [dhcwg] Brokenness of specs w.r.t. client 
>behavior with M&O bits
>
>Not trying to oversimplify things here, but to me it makes the 
>most sense to start with what we have working now and *not* 
>make any broad, sweeping changes.  To do otherwise is not only 
>a tremendous disservice to all of those who have 
>implemented/adopted IPv6 (or are considering doing so) but 
>I am in no way saying we can't continue adding capabilities 
>(e.g. - XML config via RA-provided URL) ... but to make 
>drastic changes to functions that real people are using in 
>real networks to provide real services seems, well, sub-optimal.
>
>
>What we have:
>	SLAAC
>	Stateless DHCPv6
>	Stateful DHCPv6
>SLAAC is well defined, and works quite well - even w/o 
>DNS-option support being widespread.  Once RFC5006 support is 
>in place, this will be sufficient for most uses, with a valid 
>concern about the host identification /
>(dynamic) name resolution areas.  We can address those, rather 
>than toss the baby with the bath water.
>
>DHCPv6 is also well defined, with some questions rising around 
>the acillary pieces - e.g. when does a host run it, and choose 
>which mechanism.
>IMHO,
>In my world view, the following would be the least painful and 
>most functional approach:
>	Host sends RS
>		... if one RA specifies one approach, and one 
>RA specifies the another, do both ...
>	If no RA received, I am OK with the host making a 
>one-shot attempt at both stateless and stateful DHCP, just in case
>		... the question here - what is the assumed 
>prefix length / "on link" approach?
>			... if we stick with the "right" answer 
>of /128, well then DHCPv6 didn't accomplish much
>			... if we assume /64 we raise other 
>problems / questions
>		I think this case is somewhat degenerate and 
>should be rare; but should nonetheless have a consistent, well 
>defined behavior.
>
>
>
>PS - I totally agree with Iljitsch's "the amount of people 
>that complain that IPv6 changes too much seems to be about the 
>same as those that complain that IPv6 doesn't change enough so 
>my guess is that they got this more or less right" ... I 
>believe another relevant quote would be "rough consensus and 
>running code".
>

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 23 Oct 2008 13:48:57 +0300

Hi, 

>Behalf Of ext Ted Lemon
>Sent: 16 October, 2008 20:49
>To: Iljitsch van Beijnum
>Cc: David W. Hankins; [email-masked]; List Mailing; DHC WG
>In order for this to be a valid rejoinder, it would have to be 
>the case that the cellular industry was planning to use IPv6 autoconf  

At least latest 3GPP specifications support solely SLAAC and stateless
DHCPv6, so DHCPv6 for stateful address autoconfiguration is currently
not supported per latest 3GPP standard at all (see chapter 5.3.1.1 at
3GPP 23.401
http://www.3gpp.org/ftp/Specs/archive/23_series/23.401/23401-830.zip ):
--cut--
Both EPS network elements and UE shall support the following mechanisms:
  a. IPv4 address allocation via default bearer activation, if IPv4 is
supported.
  b. /64 IPv6 prefix allocation via IPv6 Stateless Address
autoconfiguration according to RFC 4862 [18], if IPv6 is supported;

Furthermore, the Protocol Configuration Options may be used during
bearer activation to configure parameters which are needed for IP
address allocation.

Both EPS network elements and UE may support the following mechanisms:
  a. IPv4 address allocation and IPv4 parameter configuration after the
attach procedure via DHCPv4 according to RFC 2131 [19] and RFC 4039
[25];
  b. IPv6 parameter configuration via Stateless DHCPv6 according to RFC
3736 [20].
--cut-- 

Therefore there's no problem for a host to think how to configure its
IPv6 address - only single way is supported.

The host to always having guaranteed /64 bit prefix on 3GPP access is
also advantageous for network connection sharing use-cases, as the host
can simply act as a ND proxy. If the host would be using DHCPv6 and get
just a single /128 IPv6 address, how the host could then share the
connection for other devices (like laptop) in LAN behind the host? By
utilizing DHCPv6 Prefix Delegation - but is it guaranteed that a host
using DHCPv6 for address configuration _always_ can ask also for a
prefix from DHCPv6 server with DHCPv6 PD? By acting as bridge - but what
if the hosts in the LAN do not support stateful DHCPv6?

Best regards,

	Teemu

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 23 Oct 2008 13:06:31 +0200

> Updating an XML schema every time you get a new option is no  
> different than updating a server configuration or client  
> configuration to understand a new option.   Most existing DHCP  
> clients and servers are able to be so updated by the user, without  
> any requirement for a software update, just as would be the case  
> with XML/HTTP.

Really? Where in my Mac DHCPv6 (oh wait-it doesn't do DHCPv6!) where  
in my Vista DHCPv6 config do I add support new DHCP messages?

Generality in parsing binary formats has traditionally been a huge  
security hole. Then there is the issue of the MTU that limits the  
amount of info that you can put into DHCP without scary workarounds.

Whichever way you slice it, DHCP is a technological coelacanth.

> hypothetical problem.   We need to solve the real problem.   All  
> these digressions on which protocol is better are fascinating, but  
> not to the point, unless the solution is to deprecate one protocol  
> or the other, which I think is unlikely.

> So we need to come up with some actual guidance as to what  

Right. But what's the problem exactly?

Didn't we specify what needs to happen in RFC 246x? I see no  
compelling reasons to revisit the original intent of the M/O bits, and  
sufficient reason to not do so.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 23 Oct 2008 13:11:50 +0200

On 17 okt 2008, at 22:54, Bernie Volz (volz) wrote:

> possible).

Fully agree. However:

> What client vendors ship the default as is up to them as it
> depends on the target customer/market.

Disagree with that. We've seen in the past that if a large vendor  
enables some kind of automatic behavior that's undesired in some  
situations, it's pretty much impossible to clean this up unless you're  
talking about highly managed environments. (See all the trouble that  
Windows dynamic DNS updates can cause.)

If the default isn't to respect the M/O bits, then:

> completely useless and thus effectively deprecated.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 23 Oct 2008 13:18:10 +0200

Replying to your change of subject, not (necessarily) the message  
itself:

At the last IETF meeting, I captured a bunch of wireless traffic  
during the plenary with the idea to analyze the broadcasts to see how  
much airtime they take up. Unfortunately, I didn't get around to it  
and deleted the file.

I'll try to do this and come up with an analysis the next available  
opportunity. Perhaps we can wait with reaching a conclusion until that  
has been done?

Iljitsch

---

From: "hyunwook cha" <[email-masked]>
Date: Fri, 24 Oct 2008 10:15:03 +0900

Hello, Tony.

Thank you for your agreement and interests in the issues being
addressed by the draft "draft-cha-ipv6-ra-mo-00.txt".

Since I feel that we need to discuss how to solve the issues more, I
would like to insert my comments as below.

2008/10/24 Tony Hain <[email-masked]>:
> I agree with Joseph that these should be combined and published.
>
> As for dealing with conflicting M&O, just OR the received set. When the
> state changes from 1 to 0 (actually in either direction), after a random
> delay re-query DHCP to verify the lease time/config information. In a
> managed configuration, this would be a simple way to abruptly revoke
> outstanding leases, without allowing a rogue RA to drop existing state. The
> most the rogue RA would do is generate extraneous traffic to the DHCP
> server.
>

I think that you mean by "OR" that the state of M/O bit should remain
1 as long as a RA is received with M/O set to 1. If you consider to
implement this, you might agree more complexity suggested by our
draft. That is, timer based management scheme of bit states. I see
possible cases that states should be able to be clear. Administrator
may change network policy from stateful addressing to stateless one.
Or administrator may fix the misconfiguration by clearing M/O bits in
RA mistakenly set. Or, once a dual homed site is connected with two
domains provisioning stateful addressing and stateless one
respectively, the upstream connection to the stateful domain may be
removed later. Through our scheme, the state variables can be changed
from 1 to 0 after some pre-defined delay.

As for re-quering DHCPv6 to verify the lease time/config information,
I also agree that this may be one option. However, if there are RA
messages with conflict M/O bits being sent frequently by multiple
routers, this might generate much extraneous traffic to the DHCPv6
server. For this case, hosts do not have to generate extraneous DHCPv6
traffic as long as one valid router sends its RA with M/O bit set to 1
if our scheme is applied. Only if no RA are received with M/O bit set
to 1 within pre-defined delay, the state will be changed to 0. Then,
your suggestion may be one option.

As for options that we may choose, two another options are suggested
in the draft. First one is that a client refer states just to check
that it should keep its operation, i.e it is allowed to send
Solicit/Info-request multicast messages only when lease or information
refresh timer expires. If the state is 0, client terminates. According
to the RFC3315, DHCPv6 server may send a Reconfigure message to inform
new or updated configuration parameters, then client initiate a
Renew/Reply or Information-request/Reply transaction. So, if the
server send the Reconfigure message right before its termination or
service change from stateful to stateless(RFC3736), leases of clients
can be invalidated early and safely through the DHCPv6 protocol. The
other option is that state transition from 1 to 0 makes client be
revoked immediately. Even though this sounds unreasonable and unsafe,
it will cause no serious problems since this might happen only if no
RA messages are received with M/O bits set any more.

Joseph

> I would also like to clarify a point raised by Iljitsch; the reason the
> number of people complaining about too many changes is the same as those
> complaining about not enough, is due to both arguments being raised by the
> same people. Basically people are whining that their favorite change isn't
> happening, so no other change should be allowed either. This is essentially
> why we ended up with the state where both an RA and DHCP are required,
> rather than both mechanisms being self-contained and available to deal with
> different deployment scenarios. Some people demand central control, and they
> should have all the capabilities within DHCP to do so, while others want to
> minimize points of configuration to maintain, and they should also have a
> complete set of capabilities. While RFC 5006 fixes the DNS piece, there is
> no hint that SRV records allow completing that picture.
>
> FWIW: the people that are promoting the concept that IPv6 is just IPv4 with
> more bits, are simply refusing to recognize that they need to learn
> something new. They have tied their value in the marketplace to IPv4, and
> are trying to convince the market they are still relevant.
>
> Tony
>
>
>> Hello, Ralph and all.
>>
>> proceed.

---

From: "hyunwook cha" <[email-masked]>
Date: Fri, 24 Oct 2008 11:23:55 +0900

Hello, David.
A few comments are inserted.

> their will to receive further unicasts.

What if DHCPv6 servers do not exist? AFAIK, in this thread, the cost
of unnecessary multicast DHCPv6 messages which may be prevented
through M&O bits are being discussed.

> very low.  So no spurious ND multicasts.

This does not comply with RFC4862. See section 5.4.

5.4.  Duplicate Address Detection

   Duplicate Address Detection MUST be performed on all unicast
   addresses prior to assigning them to an interface, regardless of
   whether they are obtained through stateless autoconfiguration,
   DHCPv6, or manual configuration, with the following exceptions:

AFAIK, IPv6 stack in OS kernel does not provide special interface for
address configuration by DHCPv6 client. This means that manual
configuration using shell command like "ifconfig ..." or CLI command
like "ipv6 address ...." and autoconfiguration through DHCPv6 are not
distingushable, so DAD is performed per configured address. This is
right and robust way as the RFC says. As you know very well, DHCPv6
has a Decline message to deal wih duplicate addresses.

> disable DHCPv6 client transmission by clearing the bits.
According to RFC2461/2462, there is no implication for what you are saying.

> believe they possess today.
Right. As I presented last 71st IETF dhc meeting, Vista does not
comply with the RFCs in that client send Release messsages to
invalidate bindins in server and remove obtained addresses when it
receive RA with M flag set to 0 (I am not sure that this is latest
behavior.)  However, this may be not the case of many other
implementations. Since both current and old specifications do not deal
with the transition of bits, we believe that clear docuement should be
published addressing known issues in our draft.

Joseph

---

From: "hyunwook cha" <[email-masked]>
Date: Fri, 24 Oct 2008 11:38:48 +0900

Hello, Teemu.

A few comments are added below.

> Used link-layer does have an impact: on cellular networks the link-layer is nowadays most often opened on-demand (i.e. when an application starts), or quickly reopened e.g. if network connection is…

If delay time for address configuration is crucial for user, how about
DNS or other configuration informations? Are those informations
provisioned through stateless DHCPv6? Now, I guess that stateless
DHCPv6 is initiated right after the first RA is received with O flag
set to 1. Is this delay acceptable for your environment?

Joseph

---

From: "hyunwook cha" <[email-masked]>
Date: Fri, 24 Oct 2008 12:04:38 +0900

Hello, Teemu.
My comments are below.

>  b. IPv6 parameter configuration via Stateless DHCPv6 according to RFC
As for your question, I would say that it depends on implementations.
AFAIK, there are already several opensources like ISC DHCP which
supports IA_NA(maybe IA_TA) as well as IA_PD. And Windows 2008 server
also does. Even though details of implementations may be different,
site prefixes are derived from delegated prefixes and the LAN
interface is configured with addresses from the site prefixes as
pre-configured policy. Then, site prefixes are advertised through
following RA messages from the LAN interface and hosts have addresses
configured via SLAAC. However, I am not sure that ND proxy has been
deployed well.

Joseph

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 24 Oct 2008 09:38:57 -0700

> through M&O bits are being discussed.

That's a separate issue.  Iljitsch is proposing that Multicasts must
be reduced to as close to zero as possible, as a performance criteria.

If that's truly your goal, then RA is the wrong solution from the
start: it MUST use far more multicasts.

Further...

If a client sends a DHCPv6 packet, it is because it requires some
DHCPv6 configuration to use network services.

If you do not reply to that client, you are not doing it a service.
It is not 'connected to the Internet', it is operating at a lower
level of service; without appropriate configuration.

> This does not comply with RFC4862. See section 5.4.

I'm not really concerned with RFC 4862.  RFC 3315 only lists DAD
as a SHOULD.  Someone trying to save radio transmit power, as Iljitsch
suggests, would be better served to capitalize on DHCPv6 without DAD
than to waste airtime needlessly with SLAAC.

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 24 Oct 2008 11:13:47 -0700

On Thu, Oct 23, 2008 at 08:15:54AM -0400, James Carlson wrote:
> Unless your DHCPv6 server box also happens to be an IPv6 router for
> the prefix in question, I don't think you should be trying to do
> anything with RS/RA messages.

I agree completely, I would rather not ever transmit an RA.

But so long as 'successful DHCPv6 configuration' relies upon
'successful RA configuration' (consistent configuration or not;
they both have to succeed to final configuration state,
independently), then I can see few alternatives.

We can either make DHCPv6 succeed indepedently (by replacing RA
with it), or we can make DHCPv6 servers transmit RA, hoping to
approach some certainty the client is configured.

"Neither", decreeing this situation to be broken by design, is not
an option I will entertain for the long term.

We like to sit in the IETF's ivory tower and glower over
interoperation failures.  Those are clearly the problem of
implementers, operators, or both, who could not possibly understand
the purity of the ideals which our protocols cling to.

I think when the network is playing host to a hospital's
infrastructure, or an army base, you take a different view.  That
corner case that you decreed broken by design may look different from
the point of view of a man in a hospital bed, or a soldier.

But even other people's lives don't seem to have that much thrust
in getting the seriousness of any problem across.  It is, after
all, not your life on the line.

So, perhaps what I refer to as the 'xkcd criteria' is a better way
to express and understand what should be the primary motivation of
protocol design;

"When designing an interface, imagine that your program is all that
stands between the user and hot, sweaty, tangled-bedsheets-fingertips-
digging-into-the-back sex." [1]

> How can the system "default" to using /64 in the absence of any router
> prefix information?

It was actually pretty easy, and there have been no interoperation
failure reports.

Protocol design ideals don't matter nearly as much as people do.

> I understand the pragmatic part of doing that (broken configurations
> with no advertising routers will still "work" well enough for local
> destinations that users won't be upset), but I think it misses the
> bigger picture.

It isn't a misconfiguration issue.  It is an outage resilience issue.

I am unwilling to accept that DHCPv6 breaks when the router is down.

Simply: That is an unacceptable delay according to the xkcd
criteria.

If it were merely a misconfiguration issue, we'd find some way to
report the misconfiguration so it can be solved quickly (again
supporting the xkcd criteria).

> that.  The lack of a prefix length and routing information in DHCPv6
> is one of the things that is done *better* than with DHCPv4, because
> there's just one source of authoritative information.

I am also after one source of authoritative information.  I do not
think you are correctly analyzing RA+DHCPv6 as being "single source".

[1] http://xkcd.com/196/
  (image tooltip quoted)

---

From: <[email-masked]>
Date: Mon, 27 Oct 2008 08:41:58 +0200

Hi Joseph, 

>> Used link-layer does have an impact: on cellular networks 
>the link-layer is nowadays most often opened on-demand (i.e. 
>when an application starts), or quickly reopened e.g. if 
>network connection is temporarily lost for any reason. In the 
>future always-on connectivity becomes more commonplace than it 
>is today, but temporal connection failures may remain in 
>game.. So, when a connection is (re-)opened, IPv6 address 
>needs to be obtained as quickly as possibly for the reasons of 
>good user experience (user is waiting for something to 
>happen..). Often the connection is trusted point-to-point 
>connection, so there is no risk of spoofed RAs. As user is 
>waiting, there is no time to start guessing whether DHCP is 
>available or not, but address will be configured by fastest 
>means available - currently by sending RS immediately when 
>link layer gets up to ensure fastest possible retrieval of RA.
>>
>
>If delay time for address configuration is crucial for user, 
>how about DNS or other configuration informations? Are those 
>informations provisioned through stateless DHCPv6? Now, I 
>guess that stateless
>DHCPv6 is initiated right after the first RA is received with 
>O flag set to 1. Is this delay acceptable for your environment?

Some configuration information can be received during link layer
activation before IP address configuration. 3GPP 24.008
http://www.3gpp.org/ftp/Specs/html-info/24008.htm lists these, including
the DNS server addresses. If a host does not wish to/is not able use
these link layer means, it can use Stateless DHCPv6 for the
configuration. Unfortunately RFC5006 is at least not yet mentioned in
the specs. The 3GPP originally specified the link layer means I guess at
least partly because at that time RFC3736 and RFC5006 did not exist.

Another alternative to get DNS server addresses is statically when a
host is provisioned with network connection settings.

Of course RTT for a single _successful_ message exchange in modern
wireless networks is rather small (especially when compared to roughly
200ms in older ones where IPv6 was first introduced), but as the number
of messages exchanged by various protocols of different layers
increases, the time builds up. It's best to optimize wherever possible. 

Best regards,

	Teemu

---

From: <[email-masked]>
Date: Mon, 27 Oct 2008 08:50:20 +0200

Hi Joseph,

Thank you for your responses, comment inline 

>AFAIK, there are already several opensources like ISC DHCP 
>which supports IA_NA(maybe IA_TA) as well as IA_PD. And 
>Windows 2008 server also does. Even though details of 
>implementations may be different, site prefixes are derived 
>from delegated prefixes and the LAN interface is configured 
>with addresses from the site prefixes as pre-configured 
>policy. Then, site prefixes are advertised through following 
>RA messages from the LAN interface and hosts have addresses 
>configured via SLAAC. However, I am not sure that ND proxy has 
>been deployed well.

Actually I was more concerned on operator policies: if operator is
running DHCPv6, will it be their policy decision whether or not to allow
hosts to request for prefixes as well? 

Consider cellular host case:
- host implements e.g. ND proxy and DHCPv6 PD for WAN connection sharing
- host attaches to a network where only DHCPv6 happens to be used
- host gets single /128 IPv6 address from DHCPv6
- host tries to get some prefixes for its LAN interface with DHCPv6 PD,
but network's policy rejects the prefix request

Now what can host do? Tell user that the currently attached network does
not allow network connection sharing feature?

In IPv4 it is possible to do NAT to avoid this problem..

Best regards,

	Teemu

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 23 Oct 2008 14:43:47 -0700

As for dealing with conflicting M&O, just XOR the received set. When the

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 23 Oct 2008 14:49:26 -0700

> As for dealing with conflicting M&O, just XOR the received set.

Before the world erupts over trivia, that should have said OR ....

I clearly need more sleep,
Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 28 Oct 2008 16:18:48 +0100

> be reduced to as close to zero as possible, as a performance criteria.

Obviously multicasts are useful so I'm not saying we can't have any.  
But in the case above, where there is no DHCPv6 server so the client  
will be retransmitting multicast request, is clearly suboptimal,  
especially since we have a mechanism to avoid it.

> DHCPv6 configuration to use network services.

That's one of the problems with DHCP: the client doesn't know whether  
it needs configuration info, it's the server that knows whether  
clients need info. But it's the clients job to initiate the  
communication.

So the client is pretty much forced to run DHCP in case the server has  
something to tell it, unless we use a non-DHCP mechanism to avoid this  
when it's not necessary.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 28 Oct 2008 09:22:14 -0700

On Tue, Oct 28, 2008 at 04:18:48PM +0100, Iljitsch van Beijnum wrote:
> Obviously multicasts are useful so I'm not saying we can't have any. But in 

I just want to say that what I'm actually hearing in this is that
you'll waffle on the performance criteria you invented so long as it
means you get to keep RA ("ok, so RA has more multicasts, but they are
-cooler- multicasts!").  Again, this seems to me a repeat of our NANOG
discussion:  You "like" RA.  I won't even try to stop you.

The rest seems to be repeats of arguments I've already provided my own
answers to elsewhere in this thread, bringing us in a circle again.
So I will perform loop detection.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 28 Oct 2008 13:21:38 -0700

On Tue, Oct 28, 2008 at 11:06:10AM -0400, James Carlson wrote:
> Neither is the current solution described by the RFCs: you are
> required to set up both your IPv6 routers and your DHCPv6 server in
> order for the system to work consistently.

James, we're talking about different things.  You're still talking
about "misconfiguration," and to be bluntly honest, I'm bored by it.

I'd be happy to discuss this with you in a higher bandwidth setting,
if one could be scheduled, but I think additional email is not
productive.  It would probably only frustrate both of us.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Oct 2008 12:01:37 +1300

Teemu,

> not allow network connection sharing feature?

Yes. The "host" in this case is actually behaving as a CPE,
and it can report the fact that it's only able to get one
address.

The bug here is that the ISP is handing out a /128 instead of
a /48, /56 or /64. That's a business issue, and the user needs
to find a more reasonable ISP.

   Brian

---

From: "hyunwook cha" <[email-masked]>
Date: Thu, 30 Oct 2008 08:59:57 +0900

Hello, Teemu.
Thank you for your clarification.

> not allow network connection sharing feature?

Right as long as DHCPv6 server can assign only one address to the host.
One more thing I would like to know is whether the host is allowed to
configure multiple arbitrary addresses in the scenario of SLAAC plus
ND proxy in the service provider's view. If other hosts in LAN
configure addresses through SLAAC plus ND proxy, outbound traffics
forwarded by the host acting as a gateway have unknown source IPv6
addresses while source MAC address is same. Are there any issues on
this point?

Since DHCPv6 server is also able to assign multiple addresses to
single client depending on the poliy, the host can activate its server
with the assigned address except the one used by itself if it has
DHCPv6 server installed. Then, other hosts in LAN can configure their
addresses through DHCPv6 which might be invoked by proxed RA. Yes,
this approach shows more restriction than SLAAC plus ND proxy
apparently.

The other alternative for the above assumption might be the 6-to-6
NAT. However, this is very likely to generate same issues as IPv4 NAT.

Anyway I agree that the simpler way to achieve the sharing of IPv6
Internet connection is SLAAC plus ND proxy.

Thanks

Joseph

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 30 Oct 2008 07:42:07 +0200

Brian, 

(changed topic to be more descriptive)
 
>> - host tries to get some prefixes for its LAN interface with DHCPv6 
>> PD, but network's policy rejects the prefix request
>> 
>> Now what can host do? Tell user that the currently attached network 
>> does not allow network connection sharing feature?
>
>and it can report the fact that it's only able to get one address.
>

Well I'm not completely certain whether involving users here would
provide very good experience, and certainly operators would not be happy
to see vendors' devices complaining about limitations of their network:)

IMHO network that is giving out only /128 to hosts that are providing
"network sharing feature" is forcefully creating "localized IPv6 address
space exhaustion scenario" for the hosts, which I fear may be tackled
with mechanisms familiar from IPv4 address exhaustion scenarios, i.e.
with IPv6 NAPT.

I would not like to see IPv6 NAPT, but I see that as a real risk if
network is using DHCPv6 for allocating hosts just /128 addresses but at
the same time is not willing to delegate prefixes on demand. 

Best regards,

	Teemu

---

From: Pekka Savola <[email-masked]>
Date: Thu, 30 Oct 2008 09:26:00 +0200 (EET)

...
> with mechanisms familiar from IPv4 address exhaustion scenarios, i.e.

FWIW, I agree this would be a problem.

But, maybe there is an implementable workaround to this operational 
issue.  Would it be possible for the host to either 1) run DHCPv6 
again, with a different DUID or client identifier (could it get more 
/128's that way, or 2) use DHCPv6 IAs to request multiple addresses? 
Then it would proxy these specific addresses instead of a whole /64. 
If neither of these is possible, how would this scenario be different 
from the mobile terminal operating as a L2 bridge and multiple devices 
behind it requesting addresses with DHCPv6?

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 30 Oct 2008 06:49:00 -0700

>From: Pekka Savola [mailto:[email-masked]] 
>Sent: Thursday, October 30, 2008 12:26 AM
>To: [email-masked]
>Cc: [email-masked]; [email-masked]; [email-masked]; 
>[email-masked]; [email-masked]; 
>[email-masked]
>Subject: Re: [dhcwg] /128 address allocation and "localized 
>IPv6 addressspace exhaustion",was RE: Brokenness of specs 
>w.r.t. client behavior with M&O bits
>

I have a couple of related questions regarding /128s:

1) can a requesting router use DHCPv6 prefix delegation to
obtain /128's from a delegating router?

2) Must a requesting router examine the M&O bits in another
router's RAs before determining that DHCPv6 PD can be used?

Thank you,
Fred

---

From: "Ole Troan" <[email-masked]>
Date: Thu, 30 Oct 2008 22:55:33 +0900

> obtain /128's from a delegating router?

yes, but that seems a little contrived.

> router's RAs before determining that DHCPv6 PD can be used?

no. the requesting router being a _router_ does not act on information
in received RAs.
the M and O bits must not in any way affect PD operation.

/ot

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Oct 2008 15:31:27 +1300

Teemu,

On 2008-10-30 18:42, [email-masked] wrote:
> provide very good experience, 

I see your argument, but failing silently doesn't seem like a
good idea.

> and certainly operators would not be happy

Too bad. This is actually a consumer protection issue;
it seems completely appropriate to require that the
reason for failure should be notified to the paying user.

> with mechanisms familiar from IPv4 address exhaustion scenarios, i.e.

Correct. That's why we should make sure it's clearly defined as
a failure condition.

> the same time is not willing to delegate prefixes on demand. 

Agreed.

    Brian

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 31 Oct 2008 09:09:51 +0100

> I see your argument, but failing silently doesn't seem like a

It is only worse. What will actually happen then is, NAPT66.

> reason for failure should be notified to the paying user.

Failing silently or loudly are no options. You cannot blame the operator if
you expect him to subsidized your device sale. You cannot fail if your
competitor "just works" by using NAPT66.

Unfortunately, users are notoriously bad at appreciating good and clean
engineering over functional and ugly hacks.

>> the same time is not willing to delegate prefixes on demand.

Pardon my ignorance. Is there a concrete case of this in some access
network standard?
(I heard some rumors thereabout)

-- 
Rémi Denis-Courmont