Brian E Carpenter brian.e.carpen...@gmail.com writes:
Ray,
Without going into details: how about turning this into
draft-hunter-v6ops-something and having the debate over in v6ops?
I think that would be useful, personally.
Actually, let me suggest something else.
Before spending a whole
On Jun 1, 2011, at 4:42 PM 6/1/11, Thomas Narten wrote:
Brian E Carpenter brian.e.carpen...@gmail.com writes:
Ray,
Without going into details: how about turning this into
draft-hunter-v6ops-something and having the debate over in v6ops?
I think that would be useful, personally.
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-30, at 22:05 , Ray Hunter wrote:
Which source address (SLAAC/DHCPv6) would be used by the client for an
outbound session if a SLAAC address and a DHCPv6 were both configured on the
same link and with the same prefix, in the absence of a flag?
As I already said in my previous
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-30, at 22:05 , Ray Hunter wrote:
Which source address (SLAAC/DHCPv6) would be used by the client for an
outbound session if a SLAAC address and a DHCPv6 were both configured
on the same link and with the same prefix, in the absence
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
On 2011-05-31, at 11:57 , Mohacsi Janos wrote:
What about the ordering, if you get more than one DHCP addresses?
How would this be any different to the situation as we have it today? It's
rather strange arguing to say something introduces a problem, if this is not a
new problem, but one that
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
Hi,
You quoting is misleading - you getting out of context my answers.
On Tue, 31 May 2011, Markus Hanauska wrote:
On 2011-05-31, at 11:57 , Mohacsi Janos wrote:
What about the ordering, if you get more than one DHCP addresses?
How would this be any different to the situation as we have
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 31 May 2011, at 03:38, Fred Baker wrote:
I would expect, however, that the use of DHCP is something configured on the
system in question, just like it is in IPv4. Not that there is an
auto-configure option in IPv4 - the other alternative is manual
configuration, and most systems come
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 Tue, 31 May 2011 11:29:49 +0200
Markus Hanauska hanau...@equinux.de wrote:
On 2011-05-30, at 22:05 , Ray Hunter wrote:
Which source address (SLAAC/DHCPv6) would be used by the client for an
outbound session if a SLAAC address and a DHCPv6 were both configured on
the same link and
On 2011-05-31, at 15:28 , Mark Smith wrote:
1. Manual configured IP
2. DHCP
3. SLAAC with Privacy Extension
4. SLAAC with Interface ID
Some people might prefer SLAAC over DHCP.
That's why things like these are usually configurable. Just because there
exists a well defined default
On May 30, 2011, at 7:38 PM, Fred Baker wrote:
[...] IPv6 systems come, at least today, with SLAAC as the default. So there
is a requirement to configure DHCPv6, at least from that perspective. That
said, SLAAC ain't gonna happen in the absence of RAs, and you can disable RAs
on the
Ray Hunter wrote:
It's definitely going to become an operational FAQ, unless it is very
clear whether/how a network operator can force equivalent use of
DHCPv4 static address assignment for both source and destination
addresses via DHCPv6 (possibly by turning off SLAAC for assignment of
GUA
Sorry a couple of important typos on RFC numbers: email escaped too early.
Disregard previous message, and use this one.
Ray Hunter wrote:
It's definitely going to become an operational FAQ, unless it is very
clear whether/how a network operator can force equivalent use of
DHCPv4 static
Ray,
Without going into details: how about turning this into
draft-hunter-v6ops-something and having the debate over in v6ops?
I think that would be useful, personally.
Regards
Brian
On 2011-06-01 08:52, Ray Hunter wrote:
Sorry a couple of important typos on RFC numbers: email escaped too
On May 30, 2011, at 10:38 PM 5/30/11, Fred Baker wrote:
On May 30, 2011, at 3:57 PM, Ray Hunter wrote:
This is danger of going off topic I know (maybe it should go in v6ops), but
it's important to me to be able to understand the consequences of the
discussion, so please bear with me.
On Tue, 31 May 2011 09:24:19 -0700
james woodyatt j...@apple.com wrote:
On May 30, 2011, at 7:38 PM, Fred Baker wrote:
[...] IPv6 systems come, at least today, with SLAAC as the default. So
there is a requirement to configure DHCPv6, at least from that perspective.
That said, SLAAC
On May 31, 2011, at 6:41 PM, Mark Smith
i...@69706e6720323030352d30312d31340a.nosense.org wrote:
On Tue, 31 May 2011 09:24:19 -0700
james woodyatt j...@apple.com wrote:
On May 30, 2011, at 7:38 PM, Fred Baker wrote:
[...] IPv6 systems come, at least today, with SLAAC as the default.
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
: Elevating
DHCPv6 from MAY to SHOULD Message-ID:
3044c560-f46c-477a-bd87-df252f689...@equinux.de Content-Type:
text/plain; charset=us-ascii On 2011-05-23, at 23:56 , Mark Smith wrote:
Christopher Morrowchristopher.mor...@gmail.com writes:
Just say that at startup time, invoke SLAAC DHCPv6
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
Ray,
On 2011-05-31 08:05, Ray Hunter wrote:
...
Which source address (SLAAC/DHCPv6) would be used by the client for an
outbound session if a SLAAC address and a DHCPv6 were both configured on
the same link and with the same prefix, in the absence of a flag?
Whichever RFC3484bis or the local
On May 30, 2011, at 2:12 PM, Brian E Carpenter wrote:
For example, setting the DSCP *as a function of
the source address* makes me cringe. We're going to have to get used to
the fact that IP addresses are not constants.
good grief. The only reasonable use of a DSCP is to identify the set of
This is danger of going off topic I know (maybe it should go in v6ops),
but it's important to me to be able to understand the consequences of
the discussion, so please bear with me. It's definitely going to become
an operational FAQ, unless it is very clear whether/how a network
operator can
On May 30, 2011, at 3:57 PM, Ray Hunter wrote:
This is danger of going off topic I know (maybe it should go in v6ops), but
it's important to me to be able to understand the consequences of the
discussion, so please bear with me. It's definitely going to become an
operational FAQ, unless
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
: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Thomas
Narten
Sent: Friday, May 13, 2011 6:38 AM
To: ipv6@ietf.org
Subject: Node Requirements: Elevating DHCPv6 from MAY to SHOULD
Per a previous thread, there are indications that the WG may now be willing to
recommend that DHCPv6
-
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
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 support having DHCP be a SHOULD rather than a
MAY. 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
requirements spec. If the group
decides to the contrary I can certainly accept that.
My $0.02,
Tim
Ps 127:3-5
- Original Message -
From: Thomas Narten nar...@us.ibm.com
To: ipv6@ietf.org
Sent: Friday, May 13, 2011 9:37 AM
Subject: Node Requirements: Elevating DHCPv6 from MAY to SHOULD
Per
Narten nar...@us.ibm.com
To: ipv6@ietf.org
Sent: Friday, May 13, 2011 9:37 AM
Subject: Node Requirements: Elevating DHCPv6 from MAY to SHOULD
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, 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
1 - 100 of 114 matches
Mail list logo
