Subject: RE: DHCP failures (was RE: Do you want to have more meetings outsi de US ?)

From: "Jari Arkko" <[email-masked]>
Date: Thu, 2 Aug 2007 22:53:09 +0300

I may be missing some context (I'm bandwidth challenged right now and unable to check archives). But its unclear to me where you jumped to the conclusion that DHCP problems in Chicago had something to do with a specific protocol and that this implies we need to deploy an alternate solution in IPv6. If anything, multiple solutions seem to increase the likelihood of interop and configuration problems.

Jari

---

From: "Durand, Alain" <[email-masked]>
Date: Thu, 2 Aug 2007 16:25:45 -0400

I agree. Cable networks have proven that DHCP can be scaled
to tens of million of leases...

The fact that something went wrong at IETF is no proof
that the model is broken.

  - Alain. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jari Arkko
> Sent: Thursday, August 02, 2007 3:53 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: DHCP failures (was RE: Do you want to have more 
> meetings outsi de US ?)
> 
> I may be missing some context (I'm bandwidth challenged right 
> now and unable to check archives). But its unclear to me 
> where you jumped to the conclusion that DHCP problems in 
> Chicago had something to do with a specific protocol and that 
> this implies we need to deploy an alternate solution in IPv6. 
> If anything, multiple solutions seem to increase the 
> likelihood of interop and configuration problems.
> 
> Jari
> 
> 
>

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 2 Aug 2007 14:57:53 -0700

I did not say that DHCP should be deprecated. There are real-world
situations like the ones that took down the IETF DHCP service, that are
clearly operational/implementation/deployment rather than protocol issues.
Just because some organizations run DHCP does not mean everyone else MUST
because the IETF elite refuse to allow an operationally different
alternative to be standardized. 

Tony

> From: Durand, Alain [mailto:[email-masked]]
> Sent: Thursday, August 02, 2007 1:26 PM
> To: Jari Arkko; [email-masked]
> Subject: RE: DHCP failures (was RE: Do you want to have more meetings
> outsi de US ?)
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 2 Aug 2007 15:58:16 -0700

For MANET Autoconfiguration, we believe that it will be
beneficial (if not strongly recommended) to co-locate a
DHCPv6 server on each MANET border router. Since the MANET
border routers are also the ones that provide links to other
networks, the DHCPv6 servers are available IFF the links to
other networks are available and so the fate-sharing balance
seems appropriate. This model can be extended also to ordinary
sites that are not particularly mobile nor ad-hoc, since they
are just simple cases of MANETs. Please see the following for
further details:

  http://www.ietf.org/internet-drafts/draft-templin-autoconf-dhcp-08.txt

Fred
[email-masked]  

> From: Tony Hain [mailto:[email-masked]] 
> Sent: Thursday, August 02, 2007 2:58 PM
> To: 'Durand, Alain'; 'Jari Arkko'

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 03 Aug 2007 14:36:55 +0900

i'm not too sure if the document have reached WGLC or not, but anyways,
	there are some critical comments coming up from my side.
	http://ipv6samurais.com/ipv6samurais/openbsd-audit/
	(still under development)

	overall (up to 2.1.9):
	- i'm not too sure if it is appropriate to go into middleboxes too much
	  in this document or not.  the document should clear up its standpoint
	  either to the standards side (like those who write specifications for
	  normal nodes), or to the "real life" side (like those who implement
	  middleboxes)
	- i guess we need some upper-limit on a number of hop-by-hop option
	  headers present on a packet.  i would say "at most 1", as the sender
	  can encodde as many stuffs as needed into a single hop-by-hop option
	  header.

itojun

---

From: Ralph Droms <[email-masked]>
Date: Fri, 3 Aug 2007 07:16:50 -0400

The dhc WG has received a request to develop, on behalf of network  
operators who have expressed the specific requirement that they do  
not want the operation of their network to depend on RAs, new options  
for DHCPv6 to pass prefix and default router information to a host.   
That information would allow a host to get all of its configuration  
information from DHCPv6, obviating the use of RAs.

Will the IETF elite allow the standardization of these new options to  
support this different mode of configuration or will those network  
operators who would prefer to use only DHCPv6 be forced to continue  
to use RAs?

- Ralph, who is astonished that the IPv6 community hasn't solved
   multihoming, PI vs. PA addressing, core routing table scaling,
   renumbering and ad hoc networking, but does have time to rehash,
   yet again, the problem of Making the Internet Safe from DHCP

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 3 Aug 2007 17:51:23 +0200

On 3-aug-2007, at 13:16, Ralph Droms wrote:

> not want the operation of their network to depend on RAs, new  
> options for DHCPv6 to pass prefix

Hm, didn't we already have that part?

> and default router information to a host.

That would be new...

> Will the IETF elite allow the standardization of these new options  
> to support this different mode of configuration or will those  
> network operators who would prefer to use only DHCPv6 be forced to  
> continue to use RAs?

That's not a question we can answer in isolation, it depends on our  
collective view of the IPv6 provisioning architecture.

The reason that any way to configure DNS resolver addresses other  
than through DHCPv6 was frustrated for so long was the argument that  
we shouldn't have multiple mechanisms that do the same thing. Since  
using RAs for configuring a host with one or more default routers has  
been the standard for a decade, it seems that sticking to this  
argument would make adding this capability to DHCPv6 impossible.

However, if we agree that DHCPv6 and RA based mechanisms suit  
different users, it makes sense that we give both protocols the  
capability to provide hosts with all essential configuration  
information.

(Cue discussion about what's essential and what isn't. In my opinion,  
all non-essential information and/or information that's too large  
should be handled by a layer of indirection in the form of a small  
set of URLs where it can be downloaded.)

And when we've done all that, we need to figure out how to handle the  
situation where different mechanisms supply conflicting information.

If DHCP and RAs are going to supply the same information, wouldn't it  
make sense to make the option formats the same for easy parsing by an  
implementation that handles both protocols, and for easier  
synchronization between the capabilities of the two mechanisms?

Along the way somewhere someone will have to figure out how the DHCP  
server learns the router's address, as this tends to be neither very  
predictable nor memorable in current implementations and mistakes  
have been known to happen with IPv4 DHCP.

---

From: james woodyatt <[email-masked]>
Date: Fri, 3 Aug 2007 10:42:34 -0700

On Aug 3, 2007, at 04:16, Ralph Droms wrote:
> options for DHCPv6 to pass prefix and default router information to  
> a host.  That information would allow a host to get all of its  
> configuration information from DHCPv6, obviating the use of RAs.

Alas, that wouldn't make RA obsolete.  You'd have to deprecate RA  
explicitly to make them obsolete.  Otherwise, how can nodes learn  
that DHCP isn't required?

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Ralph Droms <[email-masked]>
Date: Fri, 3 Aug 2007 13:53:10 -0400

James - You're right, RAs would not be made obsolete.  RAs would  
still be used to tell hosts to use DHCPv6; no prefixes or default  
router info would be included in RAs in this scenario.

- Ralph

On Aug 3, 2007, at Aug 3, 2007,1:42 PM, james woodyatt wrote:

>> options for DHCPv6 to pass prefix and default router information  
>> to a host.  That information would allow a host to get all of its

---

From: james woodyatt <[email-masked]>
Date: Fri, 3 Aug 2007 11:52:36 -0700

> router info would be included in RAs in this scenario.

Are the network operators who are expressing "the specific  
requirement" that their network not "depend on RA" willing to accept  
that they still need RA to signal nodes that DHCP is required for  
obtaining prefix information and default router addresses?

Or, do they want RA deprecated completely?  If they do, then I  
wouldn't like that.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 3 Aug 2007 21:26:30 +0200

> requirement" that their network not "depend on RA" willing to  
> accept that they still need RA to signal nodes that DHCP is  
> required for obtaining prefix information and default router  
> addresses?

I would be interested in seeing some more details on their  
requirements/desires.

(I was under the impression that a default router address is implied  
as the source of the RA. That is the case, but setting a router  
lifetime of 0 indicates that the source of the router advertisement  
shouldn't be treated as a defaul router.)

> Or, do they want RA deprecated completely?  If they do, then I  

Regardless of whether anyone likes it, such a change isn't deployable  
within a reasonable timeframe anyway.

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 3 Aug 2007 13:20:42 -0700

People that prefer to use DHCP should have the tools to do that (an RA
should still inform hosts that DHCP is the mechanism this network uses).
People that prefer to avoid the costs associated with that independent
service should have the tools to do that through the RA. Hosts should accept
configuration information from either. The IETF's job is to specify the
tools, not the operational deployment model. 

Jari's misguided issue about multiple mechanisms only becomes valid when it
is not possible to deploy an operational network without both (see the
Chicago fiasco). There are financial reasons for each deployment model, and
there is no real conflict between them. The IETF needs to stop trying to
force the world to go a particular way and just make sure each deployment
model is complete. That means adding the DHCP options Ralph is talking
about, as well as the RA options that fill the gap on that side. 

Tony

> From: Ralph Droms [mailto:[email-masked]]
> Sent: Friday, August 03, 2007 4:17 AM
> To: [email-masked]
> Cc: 'Durand, Alain'; 'Jari Arkko'; [email-masked];
> [email-masked]
> Subject: Re: DHCP failures (was RE: Do you want to have more meetings
> outsi de US ?)
> 
> meetings

---

From: Kevin Loch <[email-masked]>
Date: Fri, 03 Aug 2007 16:24:22 -0400

Ralph Droms wrote:
> James - You're right, RAs would not be made obsolete.  RAs would still 
> be used to tell hosts to use DHCPv6; no prefixes or default router info 
> would be included in RAs in this scenario.

If you are going to go down this path, and I hope you do: Deprecate
EUI-64 autoconfig for all purposes except link local, deprecate RA and
tell people it's OK to use less than 18.5 quintillion addresses per
subnet.  Many of us are doing that today for segments with only
routers/servers and we would like to do that wherever we please.  I
would hate to see someone hard code bit boundaries (/64), especially
based on something that is of little or no practical use.

- Kevin

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 3 Aug 2007 13:36:02 -0700

james woodyatt wrote:
> ...

To shorten a long debate, the deployment models for not using RA are
fundamentally broken to start with. They are based on the concept that an RA
would result in a shared prefix between customers, because they are not
taking the step to do L2 isolation between the aggregation point and the
customer base. On top of that the security model is wrapped up in using DHCP
as their trust anchor (never mind that spoofing a mac blows this away). 

It is perfectly fine for the DHC wg to provide the tools for these operators
to deploy the way they want to. It is not reasonable for those operators to
drive their broken deployment model on the rest of the world by insisting
that DHCP is 'the only tool'. For them the RA should indicate 'use DHCP',
while for the rest of the world the RA should indicate the DNS server so
that DHCP is not required.

Tony

---

From: Ralph Droms <[email-masked]>
Date: Fri, 3 Aug 2007 16:46:02 -0400

Tony - the network operators I was referring to are interested in  
DHCP-only operation because, in their deployment experience, RAs have  
proven problematic.  I understand the model you are referring to, but  
that model comes from a different set of network operators.

We can certainly argue about whether RAs are fundamentally more  
problematic than DHCP and whether what we need to do is fix ND or  
extend DHCP; what I am reporting is what these operators have told me  
based on hands-on experience with deployed networks.

- Ralph

---

From: Pekka Savola <[email-masked]>
Date: Fri, 3 Aug 2007 23:59:00 +0300 (EEST)

On Fri, 3 Aug 2007, james woodyatt wrote:
>> James - You're right, RAs would not be made obsolete.  RAs would still be 
>> used to tell hosts to use DHCPv6; no prefixes or default router info would 
>> be included in RAs in this scenario.
>
> Are the network operators who are expressing "the specific requirement" that 
> their network not "depend on RA" willing to accept that they still need RA to 
> signal nodes that DHCP is required for obtaining prefix information and 
> default router addresses?
>
> Or, do they want RA deprecated completely?  If they do, then I wouldn't like 
> that.

Uh, I hope you guys aren't serious.  Probably all host-side DHCPv6 
implementations always try to run DHCP regardless of RA bits.  It 
DHCPv6 server doesn't exist.. so what, at worst, a rogue server could 
feed you bad information but that would already be possible with ND/RA 
forgeries.  If it does, bingo.

If the host implementation bothers to implement DHCPv6, vendors would 
be very hard pressed to argue why exactly they shouldn't try running 
DHCPv6 on every time the host connects to a new network if IPv6 is 
enabled.

Note: I have no strong feelings on DHCP vs RA, but IMHO this is just 
pragmatics and reality.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 3 Aug 2007 14:01:57 -0700

> based on hands-on experience with deployed networks.

Other deployed networks have hands-on experience showing RA is cheaper for
them to operate, and the Chicago network was a showcase for the operational
realities that people experience every day. I am arguing there are cases for
both deployment models, so we should not be wasting energy debating between
them, we just need to fix them both so we don't hang in this bizarre state
where both are required because neither are sufficient as-is. 

If the IESG is going to insist that there has to be a one-size-fits-all
answer, they all need to be shot during this nomcom round.

Tony

---

From: Ralph Droms <[email-masked]>
Date: Fri, 3 Aug 2007 17:13:43 -0400

Tony - in my opinion, "both are required" is not necessarily a  
bizarre state.  Each performs a specific task.  Unless the Chicago  
network deployed DHCPv6 and found it problematic, I have to say that  
the Chicago network was in any way instructive to the specific debate  
about IPv6.  Lessons learned from misconfigured DHCPv4/DNS services  
have no bearing on this discussion.

- Ralph

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 3 Aug 2007 14:33:33 -0700

> forgeries.  If it does, bingo.

I wonder how much of this comes down to common sense in some
circumstances, e.g., if a node that is inclined to do DHCPv6
comes up on a link over which no RAs are heard, why would it
want to do an RS/RA exchange only to be told "go use DHCPv6"?
Wouldn't it make more sense for the node to just send the
DHCPv6 Solicit w/o incurring the extra round-trip?

Fred

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 3 Aug 2007 23:41:37 +0200

On 3-aug-2007, at 22:46, Ralph Droms wrote:

> the network operators I was referring to are interested in DHCP- 
> only operation because, in their deployment experience, RAs have  
> proven problematic.

Can you go into detail here, please?

If stateless autoconfig doesn't work the way it should, we should fix  
that if we can.

It's also possible that their deployment causes the problem, and the  
problem may extend to DHCP too.

On 3-aug-2007, at 22:20, Tony Hain wrote:

> The IETF needs to stop trying to
> model is complete.

Note that today, all IPv6 implementations (that I know of) support  
stateless autoconfiguration. It seems exceedingly unlikely that any  
vendor is going to remove that capability anytime soon, even if, for  
some strange reason, they decide that stateless autoconfig is never a  
good idea, because it won't be possible to assume the presence of  
DHCPv6 for many years to come.

On 3-aug-2007, at 22:19, Jari Arkko wrote:

> We also care about interoperability and the ability to talk to each  
> other; if we didn't we wouldn't need to work on standards. So far  
> in this thread I have heard people avoiding DHCP completely or  
> using solely DHCP. Its clear that the two extremes would have a  
> problem communicating... The architectural principles of the  
> Internet call for trying to find one solution, even if it is not  
> 100% perfect in all cases.

To me, being able to ignore DHCPv6 and use RAs only would be a  
feature. For other people, the opposite seems to be true. So as long  
as I get to use RAs and they get to use DHCP, we're all happy. Now  
obviously these days we tend to take our computers to "foreign"  
networks where the other configuration mechanism may be in place.  
Figuring out how to handle that would be an essential ingredient in  
any document that comes out of this effort.

I would also like to add that DHCPv6 is basically two different  
protocols that look alike: a stateful one and a stateless one. The  
problem here is that choosing the right variant is up to the client,  
which doesn't know whether the server will be offering stateful or  
statless information. I would like to see a situation where the  
stateless variant goes away and either the client uses full, stateful  
DHCPv6 or it doesn't do DHCPv6 at all and learns all information that  
it needs from RAs.

On 3-aug-2007, at 22:59, Pekka Savola wrote:

> If the host implementation bothers to implement DHCPv6, vendors  
> would be very hard pressed to argue why exactly they shouldn't try  
> running DHCPv6 on every time the host connects to a new network if  
> IPv6 is enabled.

That would be extremely suboptimal, because it leads to  
retransmitting requests. These are multicasts, so they take up _a_  
_lot_ of bandwidth on wifi networks.

Where did we land on the whole M/O bit issue again?

On 3-aug-2007, at 23:13, Ralph Droms wrote:

> bizarre state.  Each performs a specific task.

I'm with Tony on this one (well, maybe not about the shooting). I  
haven't written a DHCP implementation, so I'll refrain from  
commenting on how complex those are, but rather observe that DHCP  
tends to use more packets than RA and both together certainly use  
more packets, many of them multicasts, which, again, are BAD on  
wireless networks: they're almost always sent at the lowest possible  
speed and as such, take up much, much more than their share of the  
available bandwidth.

> Unless the Chicago network deployed DHCPv6 and found it  
> problematic, I have to say that the Chicago network was in any way  
> instructive to the specific debate about IPv6.
> Lessons learned from misconfigured DHCPv4/DNS services have no  
> bearing on this discussion.

It shows that the DHCP architecture is vulnerable to single points of  
failure. Many things in life are, and this is often unavoidable, but  
telling people they MUST run such a protocol for uses that can just  
as easily be served by protocols that don't suffer from such  
architectural limitations isn't a good thing.

On 3-aug-2007, at 23:16, Tony Hain wrote:

> Get over it and define both mechanisms. Let the operational  
> community decide
> what they will and will not support in their deployments.

[...]

> I am not saying DHCP is wrong, just that forcing a one-size-fits- 
> all answer
> is wrong.

Agree 100%.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 3 Aug 2007 19:10:27 -0400

On Aug 3, 2007, at Aug 3, 2007,5:13 PM, Ralph Droms wrote:

> network deployed DHCPv6 and found it problematic, I have to say  
> that the Chicago network was
                                                                         
                                not ^^^^^
> in any way instructive to the specific debate about IPv6.  Lessons  
> learned from misconfigured DHCPv4/DNS services have no bearing on  
> this discussion.
>
> - Ralph
>

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 04 Aug 2007 13:16:20 +0900

At Fri, 3 Aug 2007 07:16:50 -0400,

> operators who would prefer to use only DHCPv6 be forced to continue  

(I'm not trying to make a specific opinion about the RA-only vs
DHCPv6-only argument)

It would help if you could provide more details about the requirement:
who are exactly the operators wanting DHCPv6-only operation, why they
want to do it, what's their (technical) problem in using RA to get
configuration information that is currently provided only by RA, etc.

I doubt one can convince others to introduce something new that can
already be done by an existing feature simply because there is someone
who wants it; the important point is that why they need it and whether
it's technically reasonable.

BTW, I see one reason that we might need to provide on-link prefixes
via DHCPv6 even though RA already has this functionality: if we
operate a closed, single-link network which contains a DHCPv6 server,
a local DNS server, and any other servers that provide services in the
network, but no router, then the nodes have to communicate using
either link-local addresses or global addresses assigned via DHCPv6.
And if the nodes want to avoid link-local addresses due to its
scope-related difficulties, they need to detect other global addresses
are on-link.  However, since DHCPv6 does not provide that information
and the "on-link by default" rule is going to be deprecated in
2461bis, there is going to be no standard way for such nodes to get
the prefix information.  Note that this problem didn't exist when the
DHCPv6 protocol was designed thanks to the "on-link by default" rule
as a last resort; but now that the assumption does not hold, I think
the DHCPv6 design principle can also be revisited.

On the other hand, I personally don't see the case where we need to
provide the default router address(es) via DHCPv6.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Sat, 4 Aug 2007 07:28:52 -0400

An Internet Draft describing the requirements for "DHCPv6-only"  
operation is in preparation.  The topic was discussed in the dhc and  
v6ops meetings in Chicago: http://www3.ietf.org/proceedings/07jul/ 
slides/v6ops-6.ppt  Further discussion will take place in v6ops once  
the I-D is finished.  I brought up the topic now as a counterpoint to  
the argument "operators want DNS serves in RAs, therefore the IETF  
should standardize such a specification".

Your point about providing information about on-link prefixes in  
DHCPv6 because of the change to the "on-link assumption" is well- 
taken and was raised by Dave Thaler in the dhc wg meeting.

- Ralph

On Aug 4, 2007, at Aug 4, 2007,12:16 AM, JINMEI Tatuya / 神明達哉

---

From: Jari Arkko <[email-masked]>
Date: Sat, 04 Aug 2007 20:41:12 +0300

Tony,

> answer, they all need to be shot during this nomcom round.

If you meant me, I'm already wearing my bullet proof vest :-)

But seriously, I don't like words being put into my mouth.
I said we (the IETF) need to ask hard questions about things
like interoperability, and the case for actual need. But I
also said that we sometimes do have multiple solutions -
e.g., when there's clear need, community consensus that they
are needed, etc. One look at the IETF's WGs should convince
you that we tolerate quite a bit of multiplicity. And I also
believe the IESG's job is not to prevent the well-informed
consensus of the community from going forward unless
there's a clear technical problem.

Having said that, the desire for one solution is indeed
one of our architectural principles (RFC 1958). But
both that RFC, at least this AD, and I believe IETF
folks in general prefer applying common sense over
rigid rules. That is, not something to use to reject
improvements or prevent real needs from being
filled. Of course, this means that a good case has
to be made.

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 05 Aug 2007 08:07:31 +0200

> ... Of course, this means that a good case has
> to be made.

It was made a long time ago I think, since we always
expected strongly managed IPv6 networks where DHCP
is more suitable, and loosely managed networks
(the proverbial dentist's office network) where it
isn't. Obviously there's a grey area in the middle
where either approach would work. What's changed in
this argument?

     Brian

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Aug 2007 14:53:26 +0300

> where either approach would work. What's changed in

Not necessarily anything -- I'm not arguing against the
case, I'm arguing that we need a good justification. In the
beginning of thread, there seemed to be a jump from
IETF-69 network experiences to something quite
different, and IMHO that was not a sufficient
justification :-)

Anyway, the managed/unmanaged networks certainly are real
business situations.

Ralph and DHC are working on what the possible
case for DHCP-side prefix/default router information
would be. Some of the questions I would like to
see answered include whether there's a true
change in vulnerability to accidental/spoofed
RAs, as similar issues may also happen in DHCP.

For the DNS etc. information delivery in RAs: do we
have (a) proposals for going beyond draft-jeong,
other than changing its status, and (b) rationale why
the status upgrade or the extensions are needed?
I'm hoping the latter would also explain what we
expect to get that goes further than what
stateless-DHCP-implemented-in-a-router would
provide.

Jari

---

From: Pekka Savola <[email-masked]>
Date: Fri, 10 Aug 2007 13:15:58 +0300 (EEST)

Hi itojun,

> 	(still under development)

Yes -- in fact, it's already in RFC-editor's queue, so the possibility 
of making non-editorial changes is rather slim.

> 	  normal nodes), or to the "real life" side (like those who implement

There has been significant debate about this, and much of it during 
IESG review (see https://datatracker.ietf.org/idtracker/ballot/2044/), 
so changes at this time are likely very substantial and not possible.

> 	  can encodde as many stuffs as needed into a single hop-by-hop option

Yes, that would be a good idea, but would need to be done in a spec 
that updates RFC 2460 or such.

You may be interested in draft-krishnan-ipv6-hopbyhop-01.txt which 
goes even a bit further than that.  I guess this could potentially be 
a good topic for the future IPv6 maintenance WG.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 10 Aug 2007 19:40:29 +0900

>Hi itojun,

	hi!  long time no see!  were you in chicago?

>of making non-editorial changes is rather slim.

	ok, i guessed that.

>so changes at this time are likely very substantial and not possible.

	maybe you can mark each of the section title with "[spec issue]",
	"[operational issue]" or something.  of course there are some specs
	that are vague between the two.

>that updates RFC 2460 or such.

	yup.  cannot wait to see rthdr0 deprecation RFC by the way...

>a good topic for the future IPv6 maintenance WG.

	i will check it out.  thanks!

itojun
# ipv6samurais.com: saving the world with code and sword