Subject: [dhcwg] RE: Here is the reference to 6.3.4 text that is ambigious text

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 25 Jan 2008 14:33:17 -0500

Widening the audience to the DHC Working Group.

I agree that it seems to be a weird corner case which is not served
after Alain's RFC, and it wouldn't show up in either a service provider
or a serious enterprise network.  However, those who are proponents of
the on-link information extensions to DHCPv6 argue that it could
conceivably exist (imagine a small network of a bunch of machines
connected with a hub - with one of the machines running a DHCPv6 server
- where some of the machines, perhaps embedded devices, were only
capable of DHCPv6 and could not use static IPv6 addresses for some
reason and cannot process RA's because they have a small stack), and
they want to create a standard to define it.  All I ask is that that
standard not impact currently existing practice for 10 years running -
ie. It should only apply if the link has no router, and anything a
router said should take absolute precedence (even if the router
advertised no prefixes) so that there would be no practical impact on
99% of the networks out there.

- Wes Beebee

-----Original Message-----
From: Bob Hinden [mailto:[email-masked]] 
Sent: Friday, January 25, 2008 1:41 PM
To: Wes Beebee (wbeebee)
Cc: Bob Hinden; Hemant Singh (shemant); Erik Nordmark; Thomas Narten;
Josh Littlefield (joshl); Brian Haberman; Suresh Krishnan
Subject: Re: Here is the reference to 6.3.4 text that is ambigious text

Hi,

<wb>
> Perhaps the guidance that I would have to those who want to add on- 
> link prefix length to DHCPv6 would be to limit it to the case where no

> router is on the link, and have whatever comes from an RA take 
> absolute precedence over anything from DHCPv6 - ie. the DHCPv6 option 
> would be completely ignored if any RA were received.
</wb>

I am confused by a scenario where there is a DHCPv6 server but no
router.  That doesn't seem like a configuration that would exist in
practice.

Thanks,
Bob

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

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 25 Jan 2008 13:50:39 -0800

> standard not impact currently existing practice for 10 years running -

since no IETF document can dictate what people will actually do with
or implement with it, there is never any danger of such a thing.

so this requirement will be most simplistic to fulfill, we won't even
have to try.

> 99% of the networks out there.

on second thought, why don't we just let DHCPv6 provide a complete
replacement for RA/RS, and if the market selects it, permit them to
migrate and obviate RA/RS entirely?

it wouldn't affect RA/RS proponents in the slightest; if you want to
continue to use technology based loosely off IPv4's ICMP Router
Discovery (circa 1994? and never truly adopted), you are perfectly
welcome to.  no one here will tell you how to build your network.

the rest of the 21st century might decide to do something that builds
upon our existing operational experience with that technology instead,
and that's not the IETF's decision to make.

people still run VMS boxes in their basements after all.  the fact
that newer, better things exist for getting a job done doesn't mean
anyone will stop them.

RA/RS and DHCPv6 both deliver configuration state to clients.  this is
a classical overlapping problem space, and the IETF is putting forth
two tools to accomplish one job.  throwing spaghetti at the wall to
see what sticks.

the way i see it, the only choices i'm aware of to make progress are
to either complete RA/RS (by turning it into something that looks
remarkably identical to DHCPv6) or complete DHCPv6 (by giving it the
ability to deliver all configuration state).

i personally think the latter of these two choices is the better one,
based upon my familiarity with both of them, and i'm unaware of any
third choice worth selecting.

in particular, continuing to force the market to require two
protocols to cover this one space is bad policy that will only end in
ruin.

> router.  That doesn't seem like a configuration that would exist in

only if the server and router were colocated.  consider the obvious
general case scenario where the network does have a router, but it
is offline.  there are a few people who think that in such a case,
the local wire network should be permitted to find and communicate
with each other anyway using their usual, globally unicast addresses.

i guess that set is not universal.

-- 
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://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Fri, 25 Jan 2008 15:57:36 -0700

> ability to deliver all configuration state).

It seems to me that "either" is actually the wrong choice.   RA is  
really custom-made for stateless address configuration.   DHCP is  
really made for stateful.   Both are valid operational choices.    
There's been a strong draw in the IETF in the direction of choosing  
only one, which I think has been a mistake.   Your characterization of  
RA as a rehash of ipv4 router discovery is amusing, but ipv4 didn't  
really have stateless address configuration.   RA makes a lot of sense  
in the context of stateless address configuration.

So while I'm not willing to put a stake in the sand and declare that  
we should definitely do both, I certainly think the IETF as a group  
could stand to be a little more open to the possibility that "both" is  
the right answer.   And I definitely think that "RA is obsolete" is  
incorrect.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 28 Jan 2008 11:38:57 -0500

Wes ... As this email thread on the DHC WG mailing list never provides
the document(s) being discussed here, perhaps it would be useful to
provide that? 

--

I agree with Ted. There's every reason to have both.

If we allow DHCPv6 to provide RA related information (such as prefix
advertisements and default router), we need to figure out how this
information co-exists with any RA information. 

As an RA is most likely received first (since a node solicits one to
determine whether to do stateless and to obtain the M/O bits), what
happens when DHCPv6 provides RA data with any data previously received
via an RA?

And, once DHCPv6 provides the information, what does the node do with
future RAs that it receives?

And, if the DHCPv6 information expires and no DHCPv6 service is
available, what does the node do with RA data?

We have to be careful here to consider both the static case (where the
node has not moved in terms of its network connection) and the dynamic
case (where the node has been connected to a different network - even if
it did not detect a link state change such as if a switch it is
connected to is "moved").

One down side of relying solely on DHCPv6 for this data is that it can
not be as dynamic as RAs can be, especially in cases where moves occur.
Thus, I believe a means to "merge" this data is likely the only
solution.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Friday, January 25, 2008 5:58 PM
To: David W. Hankins
Cc: [email-masked]
Subject: Re: [dhcwg] RE: Here is the reference to 6.3.4 text that
isambigious text

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Jan 2008 11:45:27 -0700

> Thus, I believe a means to "merge" this data is likely the only

I think that it's probably an administrative error to provide the same  
information from two sources.   Rather than defining a way to merge  
it, I think it's fine to just specify that one source or the other is  
preferred when both are present.   I don't really agree that RA is  
more dynamic - the renew interval on DHCPv6 is under the control of  
the network administrator, and DHCPv6 provides a fine mechanism for  
renumbering.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 28 Jan 2008 13:49:51 -0500

RFC 4943 - Alain Durand's RFC entitled "IPv6 Neighbor Discovery On-Link
Assumption Considered Harmful" states that the assumption that
everything is on-link when there is no default router is not the best
answer.  The RFC changed the ND RFC 4861 so that in the case of no
default router, the host should shut down and not send any traffic.  The
problem is, this now creates a hole.  Within the strange case of having
no router but having a DHCPv6 server (which is admittedly an unlikely
scenario), you can end up with a useless network.  This can be seen as
justification for carrying some information from the RA in the DHCPv6
message (namely on-link information), but only to be used in the
scenario where an administrator may wish to override the shutdown of the
host in the case where there is no default router.  Of course, the
general idea of putting the whole RA in the DHCPv6 message to make ND
obsolete was shot down in the last IETF.  But there may be a small
portion of that idea which may have utility only in this limited
scenario.  Now the question is, does anyone care about this scenario
enough to write a draft or shall we just ignore it?

- Wes

-----Original Message-----
From: Bernie Volz (volz) 
Sent: Monday, January 28, 2008 11:39 AM
To: Ted Lemon; David W. Hankins; Wes Beebee (wbeebee)
Cc: [email-masked]
Subject: RE: [dhcwg] RE: Here is the reference to 6.3.4 text that
isambigious text

--

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Friday, January 25, 2008 5:58 PM
To: David W. Hankins
Cc: [email-masked]
Subject: Re: [dhcwg] RE: Here is the reference to 6.3.4 text that
isambigious text

So while I'm not willing to put a stake in the sand and declare that we
should definitely do both, I certainly think the IETF as a group could
stand to be a little more open to the possibility that "both" is  
the right answer.   And I definitely think that "RA is obsolete" is  
incorrect.

---

From: Richard Pruss <[email-masked]>
Date: Tue, 29 Jan 2008 05:56:54 +1000

Put the whole RA in the DHCPv6 message.

- Ric

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Jan 2008 15:19:05 -0500

I don't agree with putting anything from ND into a DHCPv6 message just
yet. I have given numerous reasons verbally at IETF 70 and also in
private emails to some IETF folks. I dislike the fact that sometimes
IETF folks jump to solutions without first understanding the
requirements or the deployment - that seems to be the problem here.

First figure out if anyone should care about a network that has only a
DHCPv6 server with no IPv6 router?  I could care less about such home
network that has been anyway deems useless by Alain's RFC and now folded
into RFC 4861. If ND and DHCPv6 work together in 99% of the network
deployments including a 200 million and counting, broadband home
subscribers networks for IPv6, this discussion is not useful. Please
focus ONLY on the requirements first.

At IETF 70, someone came to the DHC WG with a requirements draft too as
to why some of ND could be folded into DHCPv6 - something to do with
mis-configuration etc. That draft didn't get much traction, if any. Show
us some hard requirement, especially a network that affects at least a
few million subs in an IPv6 network, and then the IPv6 data WG should
give any time of day to this discussion.

Hemant 

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Friday, January 25, 2008 5:58 PM
To: David W. Hankins
Cc: [email-masked]
Subject: Re: [dhcwg] RE: Here is the reference to 6.3.4 text that
isambigious text

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 29 Jan 2008 08:27:42 -0800

On Fri, Jan 25, 2008 at 03:57:36PM -0700, Ted Lemon wrote:
> really custom-made for stateless address configuration.

Back to the drawing board, then?  Every rtsold I've inspected
implements a small state engine.

The mistake was to ever think that configuration could be stateless.
Configuration itself, the act of taking, keeping, and then changing
configuration values, is a stateful act.

The consequence of this simple oversight is the creation of a
configuration protocol that is incomplete.

> Your characterization of  
> really have stateless address configuration.

To be complete; RA is truly a recombination of design elements of
IPv4 ICMP Router Advertisement and IPv4 RARP, except with several
additional (and wholly unnecessary) moving parts that occlude its
operation.

> the right answer.   And I definitely think that "RA is obsolete" is  

RA is not /yet/ obsolete.

In my view, the IETF as a group could stand to be a little more open
to the possibility that "either" or "neither" are also acceptable
answers.

-- 
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://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 29 Jan 2008 08:46:03 -0800

> I agree with Ted. There's every reason to have both.

There is also every reason to have only one.

> information co-exists with any RA information. 

No, I do not see that we "need to".  One does not even need to say
what an option is for to get an option code assigned, just to document
its format.

Unless that has changed, it is only encouraged.

Defining a DHCPv6 option that carries prefix length or even router
locator information is simply protocol work.  It is within the charter
and scope of DHC.

Defining a mechanism of recombining conflicting values from various
sources (not limited to merely RA or DHC) is an operational question
whose answer varies greatly from network to network, and has no
meaning for example in networks that elect to operate only one
configuration protocol.

The operational work is separate.  I have no objection to people who
are interested in such work to do so within a WG or forum that is
scoped to that purpose, pursuing whatever separate issues they
perceive.  V6OPS seems plausible.

It has no place here, and it has no meaning when attached to a
protocol specification.

I encourage the authors of any drafts that seek to implement a prefix
length or carry RA option contents to focus solely on the protocol
definitions.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 29 Jan 2008 19:50:56 -0800

At Mon, 28 Jan 2008 11:38:57 -0500,

> information co-exists with any RA information. 

Indeed, and it seems to me we're returning to a discussion we had
three month ago:
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg07649.html

At the risk of being redundant or repetitive, here are some points I'd
like to make:

- Since RA already has the ability of providing on-link prefix and
  default router address information, we should be careful when we add
  duplicate functionality and just say "see what happens", based on
  the design principle described in Section 3.2 of RFC1958.
  (BTW, to be fair, I've never been a fun of the idea described in
  RFC5006 for the same reason.  To me, it was a mistake; I know this
  may sound unfair, but I hope we won't use the past mistake as an
  excuse to make yet another one)

- Even in the case where there is a DHCPv6 server in a local network
  without any "router" that forwards packets to a different link, and
  even in the case where there is a host that still needs on-link
  prefix information, the DHCPv6 server itself can provide that
  information via RA with the router lifetime being zero.

At the time of the previous same discussion, we wanted to have a new
"I-D" that was reportedly expected to provide justification of
providing duplicate feature (in my understanding, despite the
principle of duplicate avoidance).  Have we seen it yet?

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 29 Jan 2008 20:13:57 -0800

At Tue, 29 Jan 2008 08:27:42 -0800,

> implements a small state engine.

I'm afraid you missed Ted's point.  "stateless" in the context of
stateless address configuration doesn't mean the host side (i.e., the
node that sends RS and configures itself) is stateless - it surely is
stateful, because it needs to maintain some information associated
with the address, such as lifetimes.  Besides, I'm not really sure
which "rtsold"(s) you are talking about, but if those include the
KAME/BSD's one, it has a state engine only for a nomadic node to
detect network change, which is irrelevant in the context of this
thread.

> additional (and wholly unnecessary) moving parts that occlude its

I'm not sure if we are on the same page or this is just rhetoric - but
my understanding of what Ted said is: we have stateless address
autoconfiguration using RA (containing prefix information) in IPv6,
and as long as we consider it an essential part of IPv6 (which I guess
is a wide consensus in the IETF, even though I know there are some
people who dislike it) that part of the RA feature carrying the prefix
information is not a rehash of IPv4 RARP, which was way uncommon.
This sounds pretty sensible to me.  Whether the router discovery part
of RA is a rehash of its IPv4 counterpart might be less obvious, but
once we understand information directly provided by a router is an
essential part of the protocol (for address configuration),
overloading the router discovery feature is also pretty sensible to
me.

---
JINMEI, Tatuya

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 30 Jan 2008 09:01:38 -0800

On Tue, Jan 29, 2008 at 08:13:57PM -0800, JINMEI Tatuya / 神明達哉 wrote:
> I'm afraid you missed Ted's point.

I often do.

> "stateless" in the context of
> with the address, such as lifetimes.

Yes, I mean the protocol itself, not the configuration management.

By introducing configuration management, I wanted to express that the
error was to think it was possible to create a stateless way to manage
configuration management, which itself is stateful.

I do in fact mean that RS/RA themselves are stateful, and not the
managed configuration states which are a result of RS/RA's state
engines.

> Besides, I'm not really sure

I don't think it is irrelevant, the IFS_ states are at the heart of
rtsold's operation and the way it processes RS/RA itself.  At least
two of those states would not go away if you removed nomadicy.  The
M and O bit processing also uses external boolean values, which are
two-state engines, so these are three state engines in Kame/BSD which
I think can not be extracated and still call it "interoperably
implementing RS/RA".

There's been discussion recently that this is insufficiently complex,
and that the M and O bit state engines need to be combined into a
single state engine.  Clients winding up with two dhcp clients running
in various edge conditions.

I bring this up because what I'm seeing here is that the IETF
consensus is slowly seeking to introduce more and more state in RS/RA
in order to address real problems.  In short, turning RS/RA into DHCP
over the course of a million minor improvements.

I have no patience for that sort of thing.  Cut to the chase and get
it done.

I'm starting to realize however that this is fairly "off in the
weeds," and I apologize for bringing it up.  The subject is what to do
about overlapping DHCPv6 work.

> information is not a rehash of IPv4 RARP, which was way uncommon.

I am in absolute agreement that people who want to use some protocol I
don't are more or less free to do so, and that the contrary is also
true; that just because I like "A" for my needs, no one implementing
"B" MUST implement "A" in order to be compatible with other "B"s out
there.

I wish more people would think so too.

As a consequence, I am of a mind that a protocol that defines how
configuration is transmitted should not enter, beyond the very
periphery, into what is operationally done or digested from that
information.

How to combine information from multiple sources is a completely
separate issue from how to receive that information.  It should not
be assumed that everyone who compatibly chooses to do one of these
things will make the same compatibility choices for the other.

As a trivial example;  You may elect to ignore the domain name sent
in a DHCP server's response, by electing to use a manually configured
value, or a value derived from some other dynamic means.  Doing so is
not incompatible with standard DHCP.  So any statement that dictates
behaviour of precedence when there are multiple sources is irrelevant.

People will simply do what is right for them, and it will not impact
anyone else.

At best it belongs in a separate BCP, describing an operational
behaviour thought to be reasonable, a work item in some operations
area WG, and I encourage people who care about that subject to write
and discuss drafts I don't have to review on mailing lists I do not
subscribe to.

I would prefer if authors in DHC just kept it topical, simple, and to
the point: describe the protocol, and let operators sort out how to
use it.

Unless there are serious inquiries for clarification, I think my point
of view has now been adequately expressed.