Perhaps you've argued this before, but per rfc 4291, u=1, g=0 is what an IID
that was formed from a MAC address uses, not u=0. The IEEE mac bits are u=0,
g=0. In the context below, perhaps best to be clear ... Use IEEE u = g =
0? Or IID u = 1 and g = 0. (It is also a bit odd that 2nd sentence
The question that started all this was whether a REBIND can ever be used
by a server to extend the lease on an address it didn't allocate. Short
answer is no. The longer answer is no, unless there is some kind of
sharing of IAs happening, which is not specified in RFC3315.
The
Ralph:
Let's review where the consensus stands (though I'm not sure how much
past history I'm including here and that may alter my preception of
what I think this consenus means).
The M/O flags indicate the availability of DHCPv6 service for
address assignment and other configuration
.
- Bernie
-Original Message-
From: Brian Haberman [mailto:[EMAIL PROTECTED]
Sent: Monday, October 13, 2008 9:26 AM
To: Bernie Volz (volz)
Cc: [EMAIL PROTECTED]; Ted Lemon; [EMAIL PROTECTED];
[EMAIL PROTECTED]; ipv6@ietf.org
Subject: Re: Request for Advices on the draft
draft-cha-ipv6-ra-mo
The answer is inconsistent. Some DHCPv6 clients default to a /64
prefix so that this scenario works, and systems with those clients can
and do interoperate.
Those clients are broken however. Getting a DHCPv6 address assigned and
assuming it is /64 (and on link) is wrong. If there is no prefix
Lemon; [EMAIL PROTECTED]; [EMAIL PROTECTED]; ipv6@ietf.org; Bernie
Volz (volz)
Subject: Re: Re: Request for Advices on the draft
draft-cha-ipv6-ra-mo-00.txt
Hello, Brian.
As I presented last IETF 6MAN meeting, our draft aims to provide
automatic revocation of DHCPv6 clients in case
Ralph:
Your changes effectively deprecate them.
- Bernie
-Original Message-
From: Ralph Droms (rdroms)
Sent: Monday, October 06, 2008 9:59 AM
To: Bernie Volz (volz)
Cc: Ralph Droms (rdroms); Thomas Narten; [EMAIL PROTECTED]; DHC
WG; IPV6 List Mailing; Brzozowski John
Subject: Re
I support this document moving forward (with the minor fixes already
discussed on the list). Sorry for missing the last call deadline.
- Bernie
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Brian Haberman
Sent: Monday, July 14, 2008 3:17 PM
To:
* if the host has received an RA containing a PIO with L=0, it
adds that prefix to its prefix list; when sending a datagram to
I think you meant L=1 as the text in 6.3.4. Processing Received Router
Advertisements only gives explicit instructions to the host for PIOs
where L=1. It has NO
Hemant:
The on-link/off-link indication is for *ALL* of the addresses in the
prefix. That is what the default behavior is in reference to.
If the node has other information (such as from an ICMPv6 Redirect), it
would then NOT use the default behavior.
There is a MAJOR difference between
And, there's always the case where the DHCP server has lost it memory
(i.e. disk) - in that case it would have no idea what was or was not
leased.
- Bernie
-Original Message-
From: Markku Savela [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 21, 2007 6:08 AM
To: ipv6@ietf.org
Subject:
Message-
From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 21, 2007 7:26 AM
To: Bernie Volz (volz)
Cc: Markku Savela; ipv6@ietf.org
Subject: Re: Rethinking autoconfig, was Re: prefix length determination
for DHCPv6
On 21-aug-2007, at 13:02, Bernie Volz ((volz)) wrote
Hideshi:
There are really two parts to this:
1. Is DAD for the link-local done when an interface reconnect is
detected? This may be required before multicasting the Confirm.
2. Is DAD for done for the global addresses (AFTER a successful
indication from a DHCPv6 Confirm is received, since there's
of these means you can not operate on all IPv6 networks, or
you might have limited service capabilities on some.
- Bernie
-Original Message-
From: Leino, Tammy [mailto:[EMAIL PROTECTED]
Sent: Friday, August 10, 2007 7:28 PM
To: Bernie Volz (volz); Iljitsch van Beijnum
Cc: ipv6@ietf.org
Doesn't RFC 4193 already define site in a way that is clear for ULAs:
3.3. Scope Definition
By default, the scope of these addresses is global. That is, they
are not limited by ambiguity like the site-local addresses defined in
[ADDARCH]. Rather, these prefixes are globally unique,
IANA already manages things like enterprise-id numbers. And, then
there's the existing IPv4 address space (how many assigned addresses are
returned or reclaimed?).
While ULA's could potentially be used by a much larger number of
entities, they may also not be used except by larger organizations.
I think we concluded that this registry was not necessary?
I'm not sure what will happen to draft-ietf-ipv6-privacy-addrs-v2-05.txt
when it becomes an RFC. Hopefully some change will occur to bullet 4 in
sectin 3.2.1:
3.2.1. When Stable Storage Is Present
...
4. Compare the generated
||
+++++
The only change is inverting the value of the universal/local bit.
- Bernie
-Original Message-
From: Suresh Krishnan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 28, 2007 12:01 PM
To: Bernie
local link identifiers and
whether the individual/group bit applies is important and should be
resolved because it may impact future assignments for special purpose
identifiers.
- Bernie
-Original Message-
From: Bernie Volz (volz)
Sent: Wednesday, March 28, 2007 2:28 PM
To: 'Suresh Krishnan
Correct. That is NOT the issue. 3041 and 3041 bis use randomly
generated identifiers that are local (not global as mac-derived
identifiers are) and there are some RFCs that RESERVE certain ranges
within this local space. We need some place to document that list of
reserved ranges so that a
, but
if these are not an issue then that's great.
- Bernie
-Original Message-
From: Christian Huitema [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 27, 2007 7:56 PM
To: Suresh Krishnan; Bernie Volz (volz)
Cc: Alexandru Petrescu; ipv6@ietf.org
Subject: RE: Reserved interface identifier registry
No disagreement here.
However, this is NOT the fault of the list. Any RFC that defines a new
restricted range would need to point out the issue that existing
implementations may configure an address in this restricted range.
But, having an IANA registry at least gives us a mechanism by which
Cisco has one -- see Cisco Network Registrar --
http://www.cisco.com/en/US/products/sw/netmgtsw/ps1982/index.html.
- Bernie
From: Ram Kumar [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 18, 2007 2:23 AM
To: ipv6@ietf.org
Subject: reg: DHCPv6 servers
Hi,
Whatever technique you use will likely never guarantee a completely
stable address.
Manually assigned is just as good (or bad) as DHCPv6 because both depend
on some type of stable storage (so yes there is hardware associated with
it). (Well, I guess you could always rely on a human to type in the
-
From: Durand, Alain [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 26, 2006 2:00 PM
To: Bernie Volz (volz); James Carlson; Vlad Yasevich
Cc: ipv6@ietf.org
Subject: RE: address selection and DHCPv6
The question is not to get an absolutely stable address,
but to make sure that in case
To: Bernie Volz (volz)
Cc: ipv6@ietf.org
Subject: Re: address selection and DHCPv6
Bernie Volz (volz) wrote:
I would think that how an address is assigned shouldn't enter into
this.
I can't see that it matters.
What really matters is the lifetimes associated with the address. The
longest
caveats may exist for it. The text already has or zero if
there is no such process.
- Bernie
-Original Message-
From: Erik Nordmark [mailto:[EMAIL PROTECTED]
Sent: Monday, May 15, 2006 7:20 PM
To: Bernie Volz (volz)
Cc: [EMAIL PROTECTED]; ipv6@ietf.org
Subject: Re: Process id in UDP/TCP
It seems to me that having some process identified with a endpoint
(socket) has value. Yes, it may not be the actual process now using the
endpoint, but it still provides some meaningful information (such as the
process that originally created the endpoint).
I'd rather see the description change,
I'm also happy with Bob's wording (but also with what Ralph and Thomas
produced).
Bob's wording also leaves it to the DHCPv6 specifications as to how to
do DHCPv6, which is far better than putting more specific details in
RFC2461bis.
But, again, I'm happy with either and do want to see this move
Thomas:
I fully agree with you.
I think these two bits have consumed way more time than they should have
- they'll probably go down as the most contested two bits in the history
of the IETF. For something so simple, it is utterly crazy.
- Bernie
-Original Message-
From: Thomas
Jinmei:
This new text doesn't work for the O flag. It implies that only
dhcplite clients care about the O - this is not correct. *ALL* DHCPv6
capable clients need to honor the O flag - it just means that they
only do Information-Request (not Solicits).
- If the M flag is not set,
I like Thomas's suggested changes.
Though I think that are available is a bit presumptuous? It may well
be that the DHCPv6 server does not exist or that there are no additional
addresses for that client. The M-bit means run stateful DHCPv6 to see
what you get, if anything.
- Bernie
It's unclear at the moment how a DHCP server on one link is able
to describe how to use addresses available on another interface
or link.
Why would you then assume that an RA on one link could do any more? It
too would be restricted to providing policies JUST FOR THAT LINK.
I think that's likely
I believe requirement 3 is incorrectly stated; I think the discussion in
the past was to have M=0/O=0 mean that the node SHOULD NOT start DHCPv6.
I believe it was just desired that it *NOT* be a MUST NOT.
Just remember what RFC 2119 states regarding these two phrases:
2. MUST NOT This phrase,
.
- Bernie
-Original Message-
From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]
Sent: Friday, May 27, 2005 9:07 AM
To: Bernie Volz (volz)
Cc: [EMAIL PROTECTED]; Ralph Droms (rdroms);
dhcwg@ietf.org; ipv6@ietf.org
Subject: Re: [dhcwg] RE: purpose of m/o bit
On 27-mei-2005, at 14:56
if there are prefixes in an RA with the A
bit set, and the M and/or O bits are set in that RA, the host would
configure both AAC addresses and DHCP-assigned addresses.
That assumes that the DHCPv6 will provide addresses on that prefix. In
most cases, I would suspect that is not the case.
Depends on what the DHCPv6 server is configured to do.
AAC and DHCPv6 can assign addresses on the same prefix, but I would
suspect that in most deployments there is little reason to do that.
Instead, DHCPv6 would likely assign addresses on prefixes that are not
AAC.
More likley is that you have
configuration parameters).
I still believe deprecating the 2nd bit (O) is better.
- Bernie
-Original Message-
From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]
Sent: Friday, May 27, 2005 12:02 PM
To: Bernie Volz (volz)
Cc: [EMAIL PROTECTED]; Ralph Droms (rdroms);
dhcwg@ietf.org; ipv6
other configuration parameters. So, yes the servers would need to be
upgraded in order to use newer clients.
- Bernie
-Original Message-
From: Ted Lemon [mailto:[EMAIL PROTECTED]
Sent: Friday, May 27, 2005 12:40 PM
To: Bound, Jim
Cc: Bernie Volz (volz); dhcwg@ietf.org; Iljitsch van
Solicits to a stateless server won't get very
far today anyway, so we can ignore that case. And, if it fails over to
use Information-Request, great.
- Bernie
-Original Message-
From: Erik Nordmark [mailto:[EMAIL PROTECTED]
Sent: Friday, May 27, 2005 1:43 PM
To: Bernie Volz (volz)
Cc
Thomas/Jim:
I believe that most of us are in agreement on the main points -- the
bit(s) are useful and SHOULD be acted on by clients accordingly.
I believe were there are issues are in the details about what each bit
means and how they interact and what happens if they're not set
correctly.
don't care if it is two bits.
- Bernie
-Original Message-
From: Soohong Daniel [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 24, 2005 11:15 PM
To: Bernie Volz (volz); 'Bound, Jim'; 'Thomas Narten';
ipv6@ietf.org; dhcwg@ietf.org
Subject: RE: purpose of m/o bit
and some type of alarm is reasonable.
- Bernie
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jari Arkko
Sent: Saturday, May 21, 2005 12:57 AM
To: Soliman, Hesham
Cc: dhcwg@ietf.org; ipv6@ietf.org; Bernie Volz (volz); Ralph
Droms (rdroms)
Subject
Excellent points Thomas.
5. what if the M flag is set but the host does not get any DHCPv6
Advertise in the initial exchange? Is it okay to fall
back to the
RFC3736 subset? Or is it even okay to run both full RFC3315 and
the RFC3736 subset concurrently from the beginning?
This has my full support ...
I kind of like the idea of one bit to say run-DHCP if you otherwise
wouldn't but would leave the meaning as simple as that. Those hosts
that run DHCP always (because that is how they are 'configured'), would
do so.
Note that if this bit is set, it means run FULL 3315
I haven't followed this thread carefully, but are you trying to suggest
that if the M flag is set but O is not, that a client would IGNORE the
other configuration parameters received from a DHCP server in a
Solicit/Advertise/Request/Reply sequence? That seems very bad to me. And
a waste of
non-link-local addresses.
- Bernie
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Bernie Volz (volz)
Sent: Monday, May 16, 2005 9:56 AM
To: JINMEI Tatuya / ; Pekka Savola
Cc: dhcwg@ietf.org; IPv6 WG; Ralph Droms (rdroms)
Subject: RE: [dhcwg
Exactly!
-Original Message-
From: Stig Venaas [mailto:[EMAIL PROTECTED]
Sent: Monday, May 16, 2005 1:21 PM
To: Bernie Volz (volz)
Cc: JINMEI Tatuya / ; Pekka Savola; dhcwg@ietf.org; IPv6
WG; Ralph Droms (rdroms)
Subject: Re: [dhcwg] Re: IPv6 WG Last
Call:draft-ietf-ipv6-ra
To: Bernie Volz (volz)
Cc: JINMEI Tatuya / ; dhcwg@ietf.org; IPv6 WG; Ralph
Droms (rdroms)
Subject: RE: [dhcwg] Re: IPv6 WG Last
Call:draft-ietf-ipv6-ra-mo-flags-01.txt
On Mon, 16 May 2005, Bernie Volz (volz) wrote:
BTW, if you want to look at this from the router administrator's
49 matches
Mail list logo
