On 2011-05-30, at 22:27 , Philip Homburg wrote:
If you are really worried about this, then I guess you can also just assign
two prefixes to a single link and use one for SLAAC and the other for DHCPv6.
Of course this is possible, but this also means, that a node not doing DHCPv6
(because it
In your letter dated Tue, 31 May 2011 11:12:13 +0200 you wrote:
Of course this is possible, but this also means, that a node not doing =
DHCPv6 (because it does not support it or because it is disabled on the =
node), will only get an address of the SLAAC prefix and thus has to go =
to through the
On Tue, 31 May 2011, Markus Hanauska wrote:
On 2011-05-30, at 22:27 , Philip Homburg wrote:
If you are really worried about this, then I guess you can also just assign
two prefixes to a single link and use one for SLAAC and the other for DHCPv6.
Of course this is possible, but this also
On Tue, 31 May 2011, Mohacsi Janos wrote:
On Tue, 31 May 2011, Markus Hanauska wrote:
On 2011-05-30, at 22:27 , Philip Homburg wrote:
If you are really worried about this, then I guess you can also just
assign
two prefixes to a single link and use one for SLAAC and the other for
On 2011-05-31, at 11:19 , Philip Homburg wrote:
No, ND is more clever than that. All traffic between prefixes that are on-link
goes directly between the hosts. Even when the prefix is off-link it is
possible for the router the send a redirect ICMP to cause further traffic
to be directly
On Tue, 31 May 2011, Markus Hanauska wrote:
On 2011-05-31, at 11:19 , Philip Homburg wrote:
My main problem with that approach is, that not everyone has a $5000++
Cisco router available and the configuration capabilities of some more
inexpensive routers are quite limited; especially
On Tue, 31 May 2011, Philip Homburg wrote:
No, ND is more clever than that. All traffic between prefixes that are
on-link goes directly between the hosts. Even when the prefix is
off-link it is possible for the router the send a redirect ICMP to cause
further traffic to be directly between
In your letter dated Tue, 31 May 2011 11:54:57 +0200 you wrote:
I don't think this related to ND, is it? ICMP redirects also exist for =
IPv4 and IPv4 doesn't know ND. I think only difference is that ICPMv6 =
optionally allows an link layer address in the redirect message. How =
good IPv6
On 2011-05-31, at 12:10 , Mohacsi Janos wrote:
If you get /64 and you need more subnets from your provider then probably you
asked something wrong.
Or you have the wrong provider... but if this is the only provider available in
your area, that can offer you a symmetric 100 MBit/s fibre
In your letter dated Tue, 31 May 2011 12:28:01 +0200 (CEST) you wrote:
On Tue, 31 May 2011, Philip Homburg wrote:
No, ND is more clever than that. All traffic between prefixes that are
on-link goes directly between the hosts. Even when the prefix is
off-link it is possible for the router the
In your letter dated Tue, 31 May 2011 12:37:05 +0200 you wrote:
Or you have the wrong provider... but if this is the only provider =
available in your area, that can offer you a symmetric 100 MBit/s fibre =
connection for business purposes, what are you going to do? Move your =
whole company
On Tue, 31 May 2011, Philip Homburg wrote:
I hope there is a recommendation in the standard to have a knob to turn
this off? With security functions like forced-forwarding and alike, I'd
definitely not want the hosts to try to communicate directly between each
other.
A prefix only becomes
On Tue, 31 May 2011, Markus Hanauska wrote:
On 2011-05-31, at 12:10 , Mohacsi Janos wrote:
If you get /64 and you need more subnets from your provider then probably you
asked something wrong.
Or you have the wrong provider...
I agree.
but if this is the only provider
available in
On 2011-05-31, at 12:35 , Philip Homburg wrote:
The difference is that IPv4 has a model of one subnet per link.
Why do you think so? The computer I'm using right now has two IP addresses of
different IP subnets on the same network interface (and I really mean the same
layer 2 network, there
On Tue, 31 May 2011, Markus Hanauska wrote:
But don't you think it helps a lot to push a new technology to
mainstream if it is possible to also use this technology without any
expensive hardware or complicated configurations? My main argument was
(and still is), that through a couple of
In your letter dated Tue, 31 May 2011 13:06:20 +0200 (CEST) you wrote:
Absolutely, but if there is another way than to announce the on-link
prefix than might make hosts communicate directly to each other on a
subnet, that's news to me and I find this extremely interesting from a
security
On 2011-05-31, at 13:09 , Mohacsi Janos wrote:
What collision? You should use 'u' bit accrdingly:
1 - if automaticaly assigned
0 - if manually assigned.
But it is also 0 for SLAAC addresses w/ privacy extension and those are
automatically assigned, in example.
You can argument for
On Tue, 31 May 2011, Philip Homburg wrote:
I have no idea why you want hosts on the same vlan and then use L2
filtering to prevent them from communicating directly. But yes, if the
router would then start sending redirects, it would create a mess.
This has been a common deployment scenario
In your letter dated Tue, 31 May 2011 13:19:39 +0200 you wrote:
On 2011-05-31, at 12:35 , Philip Homburg wrote:
The difference is that IPv4 has a model of one subnet per link.
Why do you think so? The computer I'm using right now has two IP =
addresses of different IP subnets on the same network
On 2011-05-31, at 13:38 , Mohacsi Janos wrote:
I disagree with introduction of another flags. This requires substantial
changes in the codes Which will take ages
I took a look at the IPv6 implementations of Mac OS X (which comes from the BSD
world) and Linux a couple of weeks ago.
On 2011-05-31, at 14:01 , Philip Homburg wrote:
I would say that having an interface with two IPv4 addresses is not really in
the model.
Maybe it is rather uncommon, but it is allowed and also supported by all major
operating systems; just wanted to point that out.
But SHOULD is a bit
On Tue, 31 May 2011, Markus Hanauska wrote:
On 2011-05-31, at 13:38 , Mohacsi Janos wrote:
I disagree with introduction of another flags. This requires
substantial changes in the codes Which will take ages
I took a look at the IPv6 implementations of Mac OS X (which comes from
In your letter dated Tue, 31 May 2011 14:45:24 +0200 you wrote:
Is DHCPv6 more expensive than DHCPv4? Since even the most minimalistic =
device with IPv4 support I know of has DHCPv4 support; however, you =
might be referring to devices even more minimalistic than what I have in =
mind.
I
On 2011-05-23, at 23:56 , Mark Smith wrote:
Christopher Morrow christopher.mor...@gmail.com writes:
Just say that at startup time, invoke SLAAC DHCPv6 both. Then use
whatever is available. That would have been simple and
predictable. (And avoided 10GB of mailing list discussion!)
I'm
In your letter dated Mon, 30 May 2011 12:47:19 +0200 you wrote:
Conflict resolution is not really necessary. What kind of conflict do you have
to solve? If a network runs a DHCPv6 server that also hands out addresses, th
e network operators probably want people to use DHCPv6 over SLAAC, so if a
In your letter dated Mon, 30 May 2011 12:47:19 +0200 you wrote:
Then a node has both, a SLAAC address and a DHCPv6 address. Where is the probl
em? The only problem I can think of is the issue I was trying to discuss here
a couple of weeks ago: An address collision between SLAAC addresses and
Hi Doug,
On Tue, 24 May 2011 15:36:31 -0700
Doug Barton do...@dougbarton.us wrote:
On 05/24/2011 15:00, Templin, Fred L wrote:
Good point; yes, even DHCPv6 requires link-locals. The
link-locals could be manually configured, but it seems
reasonable to assume that they would often be
On 24 May 2011, at 00:48, Christopher Morrow wrote:
On Mon, May 23, 2011 at 7:07 PM, Manfredi, Albert E
albert.e.manfr...@boeing.com wrote:
Mark Smith wrote:
Mark, as I suggested previously, DHCP is useful in cases where you need the
IP addresses of hosts in a network to be predictable.
On Weds 25th May 2011, 09:17:40 +1200, Brian Carpenter wrote:
As far as the document currently under discussion is concerned,
surely we are done?
Absolutely yes.
And if some folks want to have a discussion about some topic
other than what this document ought to say, it would be very
pleasant
On May 24, 2011, at 01:48, Thomas Narten wrote:
The one downside is that you run DHCP even if there are no DHCP
servers. In some environments, that is extra traffic
... and an extra attack (if you happen to have RA-guard but no protection for
DHCP).
Maybe not that much of a difference, but
On May 23, 2011, at 4:48 PM, Thomas Narten wrote:
The one downside is that you run DHCP even if there are no DHCP servers. In
some environments, that is extra traffic the operator might not want. I
recall many long threads about how the cost of those extra DHCP packets on a
wireless
Hi Thomas,
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On
Behalf Of Thomas Narten
Sent: Monday, May 23, 2011 1:11 PM
To: Brzozowski, John
Cc: ipv6@ietf.org; Bob Hinden
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD
Very long thread
I simply wanted to signal our (Windows Networking) support of DHCPv6 being a
SHOULD, and I personally think the text below is entirely good.
christopher.pal...@microsoft.com
Program Manager
IPv6 @ Windows
-Original Message-
From:
-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of ext
james woodyatt
Sent: Tuesday, May 24, 2011 9:10 AM
To: 6MAN
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD
On May 23, 2011, at 4:48 PM, Thomas Narten wrote:
The one downside is that you run DHCP
Dumb question, but isn't the text making support for DHCPv6 a
SHOULD, but not making it a SHOULD or MUST to run?
Correct. It's a SHOULD to implement. Whether to use it is a separate
discussion, and neither the Node Requirements or IPv6 specs address
this.
Thomas
: ipv6@ietf.org; Bob Hinden
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD
Is the intention for the new text to relax the requirement for
auto-configuration?
No. SLAAC remains a MUST. DHCPv6 though is now a SHOULD.
For one thing, DHCP doesn't have an option
On 2011-05-25 08:14, Thomas Narten wrote:
Dumb question, but isn't the text making support for DHCPv6 a
SHOULD, but not making it a SHOULD or MUST to run?
Correct. It's a SHOULD to implement. Whether to use it is a separate
discussion, and neither the Node Requirements or IPv6 specs address
To: Brzozowski, John
Cc: ipv6@ietf.org; Bob Hinden
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY
to SHOULD
Is the intention for the new text to relax the requirement for
auto-configuration?
No. SLAAC remains a MUST. DHCPv6 though is now a SHOULD.
For one
On 05/24/2011 15:00, Templin, Fred L wrote:
Good point; yes, even DHCPv6 requires link-locals. The
link-locals could be manually configured, but it seems
reasonable to assume that they would often be autoconfigured
using SLAAC.
I'm confused (nothing new about that). In FreeBSD the OS creates
Is the intention for the new text to relax the requirement for
auto-configuration?
No. SLAAC remains a MUST. DHCPv6 though is now a SHOULD.
For one thing, DHCP doesn't have an option configure on-link prefixes,
so we still need SLAAC.
What we should have done oh-so-long-ago is ensure that you
Thomas - (hoping to fan the discussion) I think operators have expressed the
desire to operate networks in DHCP-only mode, and the response has been No,
you don't really want to operate your networks that way.
If operators came forward again with a strong desire to operate networks using
only
On Mon, May 23, 2011 at 4:21 PM, Ralph Droms rdroms.i...@gmail.com wrote:
Thomas - (hoping to fan the discussion) I think operators have expressed the
desire to operate networks in DHCP-only mode, and the response has been No,
you don't really want to operate your networks that way.
one
Christopher Morrow christopher.mor...@gmail.com writes:
one gotcha with 'dhcp only' is perhaps folks mean: slaac to signal v6
is on-net, but require full config from a dhcpv6 server.
How does a host know that v6 is available otherwise? (this may be why
someone said you don't really want to do
Thomas,
On 2011-05-24 09:11, Thomas Narten wrote:
Christopher Morrow christopher.mor...@gmail.com writes:
one gotcha with 'dhcp only' is perhaps folks mean: slaac to signal v6
is on-net, but require full config from a dhcpv6 server.
How does a host know that v6 is available otherwise? (this
Hi Thomas,
On Mon, 23 May 2011 17:11:28 -0400
Thomas Narten nar...@us.ibm.com wrote:
Christopher Morrow christopher.mor...@gmail.com writes:
one gotcha with 'dhcp only' is perhaps folks mean: slaac to signal v6
is on-net, but require full config from a dhcpv6 server.
How does a host
Mark,
On 2011-05-24 09:56, Mark Smith wrote:
...
I'm not particularly pro-SLAAC, however I sit back and wonder what is
missing from it that makes DHCP essential?
To be blunt, that conversation isn't worth having. SLAAC is clearly
essential for isolated or bootstrapping networks to
On Tue, 24 May 2011 10:13:17 +1200
Brian E Carpenter brian.e.carpen...@gmail.com wrote:
Mark,
On 2011-05-24 09:56, Mark Smith wrote:
...
I'm not particularly pro-SLAAC, however I sit back and wonder what is
missing from it that makes DHCP essential?
To be blunt, that conversation
Mark Smith wrote:
3.2 If there are several ways of doing the same thing, choose one.
If a previous design, in the Internet context or elsewhere, has
successfully solved the same problem, choose the same solution
unless
there is a good technical reason not to. Duplication of the
On Mon, May 23, 2011 at 7:07 PM, Manfredi, Albert E
albert.e.manfr...@boeing.com wrote:
Mark Smith wrote:
Mark, as I suggested previously, DHCP is useful in cases where you need the
IP addresses of hosts in a network to be predictable. I have no idea why
cable systems want DHCP, but I'm
ok, so ... as a thought experiment, in v4 you wake up, decide you have
no address and are supposed to dhcp for that..
in v6, you wake up decide you have no address (and don't know if v4/v6
are available)... if you are configured for v6 dhcp, you make that
request and get all the 'right'
On Mon, May 23, 2011 at 7:48 PM, Thomas Narten nar...@us.ibm.com wrote:
ok, so ... as a thought experiment, in v4 you wake up, decide you have
no address and are supposed to dhcp for that..
in v6, you wake up decide you have no address (and don't know if v4/v6
are available)... if you are
I guess I was thinking that today you have a device, it either is
configured to do dhcp or is manually configured or just is broken. In
the v6 world you could just forget MO and require someone to
configure (via os config tweaks that already exist for v4 anyway)
dhcpv6 if anything more
Interesting point Bob raises.
Thomas,
Is the intention for the new text to relax the requirement for
auto-configuration? The new DHCPv6 text should be in addition to support
for stateless auto-configuration to ensure other deployment models are
supported.
John
Ralph, Thomas, John,
The attributes that come to mind are those that are DNS related via
RFC6106. In theory I suppose what John mentioned could be an issue,
however, in a broadband DOCSIS environment we only support stateful DHCPv6
for provisioning today as such I do not anticipate seeing these
Alex,
In DOCSIS deployments there are no issue with RAs and we do know how to
configure the default route. DHCPv6 is used mainly for address, prefix,
and configuration information.
John
=
John Jason Brzozowski
Comcast Cable
e)
Bert,
I sent some mail earlier on this topic. We do require it for provisioning
via the WAN interface. On the LAN we aim to ensure there is greater
flexibility. I just want to make sure it is clear that cable broadband
does not require the use of DHCPv6 in the premise. This is a local
On 2011-05-16 07:40, Timothy E. Enos wrote:
Hi Bob,
Thanks for your reply. I would say that partly because there are so many
different deployment models that MAY is precisely what is informed here.
That said, an acceptable alternative for me would be that it be SHOULD
for both DHCPv6 and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Just read this thread. This is so great.
Thanks to Thomas and all for the new text.
Seiichi
(2011/05/14 8:32), Brian Haberman wrote:
All,
The chairs have determined that there is a strong consensus to
elevate DHCPv6 to SHOULD support in the
Thomas...
On May 13, 2011, at 9:37 AM 5/13/11, Thomas Narten wrote:
Per a previous thread, there are indications that the WG may now be
willing to recommend that DHCPv6 be a SHOULD for all hosts. This is
based on the following rationale:
Thomas Narten nar...@us.ibm.com writes:
I
On 13 May 2011, at 14:45, Ralph Droms wrote:
New:
t DHCPv6 xref target='RFC3315' / can be used to obtain and
configure addresses. In general, a network may provide for the
configuration of addresses through Router Advertisements,
DHCPv6 or both. Some operators have
On Fri, May 13, 2011 at 09:45, Ralph Droms rdroms.i...@gmail.com wrote:
Looks fine and appropriate to me, with one nit: s/DHCP/DHCPv6/ in the last
line.
+1
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
Please respond yes or no. Given the WG's previous hesitation to having
DHCPv6 be a SHOULD, it is important that we get a clear indication of
whether or not the WG supports this change.
Should be a SHOULD.
Fred
Thomas
Thomas,
On May 13, 2011, at 6:37 AM, Thomas Narten wrote:
Per a previous thread, there are indications that the WG may now be
willing to recommend that DHCPv6 be a SHOULD for all hosts. This is
based on the following rationale:
Thomas Narten nar...@us.ibm.com writes:
I personally would
Bob,
Bob Hinden bob.hin...@gmail.com writes:
While I support changing the requirement to a SHOULD, I would prefer
the text to be something like:
t DHCPv6 xref target='RFC3315' / can be used to obtain and
configure addresses. In general, a network may provide for the
Hi all,
In general, I support Thomas' text, but I still think some clarification is
needed:
New:
t DHCPv6 xref target='RFC3315' / can be used to obtain and
configure addresses. In general, a network may provide for the
configuration of addresses through Router
On May 13, 2011, at 12:02 PM 5/13/11, Thomas Narten wrote:
Bob,
Bob Hinden bob.hin...@gmail.com writes:
While I support changing the requirement to a SHOULD, I would prefer
the text to be something like:
t DHCPv6 xref target='RFC3315' / can be used to obtain and
configure
Hi John.
Should we give some guidance on what to do if both mechanisms are available
on a network, the methods give contradictory information? I don't think it is
enough to say that both SHOULD be supported, without giving additional
clarification on what it means when both are supported.
John...
On May 13, 2011, at 12:19 PM 5/13/11, john.lough...@nokia.com wrote:
Hi all,
In general, I support Thomas' text, but I still think some clarification is
needed:
New:
t DHCPv6 xref target='RFC3315' / can be used to obtain and
configure addresses. In general, a
Hi Thomas,
Thanks for posting this.
IMO, a SHOULD is not required in a SOHO environment (which is arguably not a
corner case for deployment). MAY works.
Just as some environments may require the use of DHCPv6, some environments
may not.
For those that require use of DHCPv6, they MAY use
Timothy,
On May 13, 2011, at 9:28 AM, Timothy E. Enos wrote:
Hi Thomas,
Thanks for posting this.
IMO, a SHOULD is not required in a SOHO environment (which is arguably not a
corner case for deployment). MAY works.
Just as some environments may require the use of DHCPv6, some
On Fri, 13 May 2011, Thomas Narten wrote:
Per a previous thread, there are indications that the WG may now be
willing to recommend that DHCPv6 be a SHOULD for all hosts. This is
based on the following rationale:
I support moving it to SHOULD.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
9:28 AM
To: Thomas Narten
Cc: ipv6@ietf.org
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD
Hi Thomas,
Thanks for posting this.
IMO, a SHOULD is not required in a SOHO environment (which is arguably not a
corner case for deployment). MAY works.
Just as some environments may
Hi Ralph,
I think the IETF has been pretty good about keeping the information from the
two sources independent. Regarding address assignment specifically, what
contradictory information might be provided? I can imagine a node might get
one address from SLAAC and another from DHCPv6, but
I also think that dealing with this issue in more detail may not be so easy,
and it would be better to do that as updates to those documents (or a
standalone
document).
E.g., even DHCP by itself has a longstanding vagueness about how to handle
the merging of information received from
; Bob Hinden
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD
Thomas,
On May 13, 2011, at 6:37 AM, Thomas Narten wrote:
Per a previous thread, there are indications that the WG may now be
willing to recommend that DHCPv6 be a SHOULD for all hosts. This is
based
On Fri, May 13, 2011 at 1:12 PM, basavaraj.pa...@nokia.com wrote:
I support elevating the requirement for DHCPv6 on nodes to a SHOULD.
+1
(and thanks!)
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
New:
t DHCPv6 xref target='RFC3315' / can be used to obtain and
configure addresses. In general, a network may provide for the
configuration of addresses through Router Advertisements,
DHCPv6 or both. Some operators have indicated that they do
not intend
Le 13/05/2011 18:25, Thomas Narten a écrit :
Hi John.
Should we give some guidance on what to do if both mechanisms are available
on a network, the methods give contradictory information? I don't think it is
enough to say that both SHOULD be supported, without giving additional
clarification
Le 13/05/2011 15:37, Thomas Narten a écrit :
Per a previous thread, there are indications that the WG may now be
willing to recommend that DHCPv6 be a SHOULD for all hosts. This is
based on the following rationale:
Thomas Nartennar...@us.ibm.com writes:
I personally would support having DHCP
On May 13, 2011, at 09:28 , Timothy E. Enos wrote:
Just as some environments may require the use of DHCPv6, some environments
may not.
Mobile hosts SHOULD implement DHCPv6 clients.
I wouldn't oppose elevating the requirement further still to say that mobile
hosts MUST implement DHCPv6
Hi Thomas,
On 11-05-13 09:37 AM, Thomas Narten wrote:
Please respond yes or no. Given the WG's previous hesitation to having
DHCPv6 be a SHOULD, it is important that we get a clear indication of
whether or not the WG supports this change.
Yes. I think that elevating DHCPv6 support to SHOULD
On May 13, 2011 11:28 AM, james woodyatt j...@apple.com wrote:
On May 13, 2011, at 09:28 , Timothy E. Enos wrote:
Just as some environments may require the use of DHCPv6, some
environments may not.
Mobile hosts SHOULD implement DHCPv6 clients.
I wouldn't oppose elevating the requirement
Per a previous thread, there are indications that the WG may now be
willing to recommend that DHCPv6 be a SHOULD for all hosts.
aol
fwiw, there are large broadband providers that provision using dhcpv4
today.
randy
IETF IPv6
I do not believe there needs to be special wording for mobile
Or for any other specific deployment for that matter. The reason I
mentioned cable is because many popular operating system-based hosts as well
as specific devices have to be able to operate in a cable environment and
the
On May 13, 2011, at 11:34 , Cameron Byrne wrote:
On May 13, 2011 11:28 AM, james woodyatt j...@apple.com wrote:
Mobile hosts SHOULD implement DHCPv6 clients.
I wouldn't oppose elevating the requirement further still to say that
mobile hosts MUST implement DHCPv6 clients.
Why? Most
On 5/13/11 1:56 PM, ext james woodyatt j...@apple.com wrote:
On May 13, 2011, at 11:34 , Cameron Byrne wrote:
On May 13, 2011 11:28 AM, james woodyatt j...@apple.com wrote:
Mobile hosts SHOULD implement DHCPv6 clients.
I wouldn't oppose elevating the requirement further still to say that
On 5/13/11 1:56 PM, ext james woodyatt j...@apple.com wrote:
On May 13, 2011, at 11:34 , Cameron Byrne wrote:
On May 13, 2011 11:28 AM, james woodyatt
j...@apple.com wrote:
Mobile hosts SHOULD implement DHCPv6 clients.
I wouldn't oppose elevating the requirement further
I support the idea of making DHCPv6 a SHOULD, and like the text revision
proposed by Bob as amended by Ralph.
As to the clarification of what to do in the event of inconsistent
information when both methods are used, I agree that RFC 4862 covers
it. If pushed, citing that RFC would be
Ed Jankiewicz wrote:
The comment from Tim that the DHCPv6 man not be of use in SOHO
deployments, I think SHOULD still leaves enough wiggle room for a
variety of implementations with different feature sets.
I support SHOULD for DHCPv6 as well.
But responding to the above, purely
I agree with Ralph's text.
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Ralph Droms
Sent: Friday, May 13, 2011 9:23 AM
To: Thomas Narten
Cc: ipv6@ietf.org; Bob Hinden; Ralph Droms
Subject: Re: Node Requirements: Elevating DHCPv6 from
Per a previous thread, there are indications that the WG may now be
willing to recommend that DHCPv6 be a SHOULD for all hosts. This is
based on the following rationale:
I support moving it to SHOULD.
Agreed.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
All,
The chairs have determined that there is a strong consensus to
elevate DHCPv6 to SHOULD support in the node requirements document.
Since this is the last open issue with this document, the chairs will
begin the advancement process when a new version is published.
Regards,
Brian Bob
On
92 matches
Mail list logo
