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 s
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 s
I've been trying to get the DHC WG to address this issue but there appears to
be zero interest in doing anything about it - see
http://www.ietf.org/mail-archive/web/dhcwg/current/msg14315.html.
- Bernie (from iPad)
On Jun 27, 2013, at 7:18 AM, "Ralph Droms"
mailto:rdroms.i...@gmail.com>> wrote
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 info
>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
mething that really isn't an issue.
- 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
IL PROTECTED]
Sent: Tuesday, October 07, 2008 8:41 PM
To: Brian Haberman
Cc: Ted 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
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
)
Sent: Monday, October 06, 2008 9:31 AM
To: Thomas Narten
Cc: Ralph Droms (rdroms); [EMAIL PROTECTED]; DHC WG; IPV6 List
Mailing; Bernie Volz (volz); Brzozowski John
Subject: Re: [dhcwg] Request for Advices on the draft
"draft-cha-ipv6-ra-mo-00.txt"
Thomas - you wrote:
> unless somethin
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: ipv6@ie
* 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 instruc
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 say
Cisco has been shipping DHCPv6 server support in Cisco Network Registrar
since January 2006. It supports stateless, stateful, and PD.
And, of course we have various degrees of DHCPv6 support in IOS (relay,
PD client/server) depending on the release.
- Bernie
-Original Message-
From: Ilji
Then why do you need a gateway (default router) address?
- Bernie
-Original Message-
From: Bill Manning [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 18, 2007 2:02 AM
To: John Jason Brzozowski
Cc: ipv6@ietf.org
Subject: Re: DHCPv6 - does it have gateway option
presume the a
--Original 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)) wro
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:
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'
one more thing to implement and test, but it
can't exactly take up a huge amount of memory.
- Bernie
-Original Message-
From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]
Sent: Monday, August 13, 2007 5:56 AM
To: Bernie Volz (volz)
Cc: Leino, Tammy; ipv6@ietf.org; John Jason B
DHCP server address would be useless because clients don't generally
unicast to the server/relay (and aren't allowed to unless the server has
sent a server-unicast option). And, if the server isn't on-link, unless
the client has an address of sufficient scope, it couldn't communicate
with the serve
ts are set.
Missing any 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 Beijn
The PIOs in an RA tells a node whether it can autoconfigure or not via
the A bit. If the A bit is not set, the node can not use SLAAC. But, it
CAN use the PIO information to build the table of what prefixes exist
and which are on-link.
That is why there is no need for DHCPv6 to provide default rou
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. D
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 ident
t this
reserved list was. Leaving it unspecified just causes folks to wonder
what the list might be -- hence my original suggestion for having it an
IANA managed list.
- Bernie
-Original Message-
From: Templin, Fred L [mailto:[EMAIL PROTECTED]
Sent: Friday, March 30, 2007 6:22 PM
To: Chri
tion the individual/group bit, just the universal/local.
So, it is a bit unclear.
- Bernie
-Original Message-
From: Suresh Krishnan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 28, 2007 2:17 PM
To: Bernie Volz (volz)
Cc: ipv6@ietf.org
Subject: Re: Reserved interface identifier regi
tion about "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
t: Wednesday, March 28, 2007 12:01 PM
To: Bernie Volz (volz)
Cc: ipv6@ietf.org
Subject: Re: Reserved interface identifier registry
Hi Bernie,
> Instead of step 4, perhaps step 4 (or as part of 3) should state
> that the individual/group bit (bit 7) should be set to 0 to
> indiciate
ISATAP, 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
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
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
i
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,
48 PM
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 assoc
ginal Message-
> 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 a
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
>If we're to compare, I'd compare the ICMPv6-PD effort with the RA
option
>to carry DNS Server effort. If things are to evolve quicker then we
>could skip some intermediary steps.
Exactly. Why have two ways to the same thing! That's another effort that
should be terminated.
Gee, why don't we ju
I think another point is that if they're concerned about having to run a
separate DHCPv6 client "process" to handle PD (as was I think discussed
in an earlier email), there's nothing in the DHCPv6 specification that
says you can not implement DHCPv6 in the IPv6 kernel. If PD is integral
to your net
y do so after a very long time).
I would argue that it is up to the implementer, perhaps based on what is
possible for the platform.
- Bernie
> -Original Message-
> From: Erik Nordmark [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 18, 2006 1:39 PM
> To: Bernie Volz (vol
what 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.or
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 Nart
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
> -Orig
>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 like
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, o
> 4 Ability to do DHCP without having to configure routers
I'm not sure I'd draw that conclusion. I think the point was that hosts
*MAY* ignore any RA "hints" and do what they are manually configured to
do - whether that is to run DHCPv6 always or never. But this is not
something that needs to be
Does anyone really see any value in 1?
And this is always possible - just don't configure the DHCPv6 server
with any configuration parameters to send out.
- Bernie
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Bound, Jim
> Sent: Friday, May 27,
bunch of implementations
under development so if we wait much longer ...).
An old client that sends 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-
>
ld server won't send
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: Bern
se with just other 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
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 a
> 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. How
able. It is just new
clients with old servers that may have issues.
- 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@iet
We don't but it avoids issues with backwards compatibility (though I
don't believe that is a big issue yet).
I think if we come to agreement on having no distinction between the
bits, we should deprecate one of the bits (O-bit?); though for backwards
compatibility, we can't remove/reassign it unti
So Rich, I'll ask. What would you like to see happen?
- Bernie
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Woundy, Richard
> Sent: Wednesday, May 25, 2005 1:39 PM
> To: Iljitsch van Beijnum; Thomas Narten
> Cc: dhcwg@ietf.org; IETF IPv6 Mailin
eally 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;
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.
Pers
ssue until the
server returns -- modulo the probe interval) or the bits were set
incorrectly 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
Hesham:
> => You can try, but my concern is about how often you're going to try.
> If there are bits that say whether you should try or not and those
> bits are not set (i.e. no DHCP server in the network), why
> would you try?
This means that the wiresless operators will get more revenue from
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 331
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 begin
e" status for any Solicits it receives.
That way, if the only servers to respond to Solicits all return "no
stateful service available", the client knows what to do.
- Bernie
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Be
AC is independent of stateful (DHCPv6).
- Bernie
> -Original Message-
> From: timothy enos [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 16, 2005 10:00 PM
> To: Bernie Volz (volz); 'Pekka Savola'
> Cc: dhcwg@ietf.org; Ralph Droms (rdroms); 'IPv6 WG'; 'J
t; Sent: Monday, May 16, 2005 5:09 PM
> 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) wrot
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 La
sources since they have
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
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 resource
Isn't the reason more basic ... As these are not globally administered,
there are no plans to build out the zones to contain the reverse delegations
(since there's no one to officially designate the zones to).
- Bernie
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTE
If there's relay specific information that could be used by a server (or
other relay), there is no reason the relay can't include this in its
Relay-Forw message (and the server return information in the Relay-Reply).
Note that Appendix A, Appearance of Options in Message Types, indicates that
thes
Seems to me that:
If M is set(1), a client able to do stateful, does stateful (or full 3315)
and ignores the O bit. This client can always fall back to stateless if it
receives a NoAddrAvail status for a SOLICIT (as per 17.1.3) and receives no
other ADVERTISEs it can use. Though this behavior isn'
I also agree with this. I think this would be useful and there is no harm.
- Bernie
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Ralph Droms
> Sent: Thursday, August 12, 2004 9:26 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Stateful != M , Statele
Alain:
And, if hosts just run DHCPv6 anyway, it makes the job of the rogue server
user even easier - since it need not even bother to generate RAs. So,
security is no better or worse. It may even be slightly better if they need
to generate the RAs since a) it is more work (especially if SEND is us
I'm for (1) DHCPv6 and a reference to RFC 3315 (X).
- Bernie Volz
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, April 13, 2004 3:10 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [rfc2462bis] what i
Jinmei requested I send this to the IPv6 mailing list.
-Original Message-
From: Bernie Volz [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 02, 2004 6:06 PM
To: 'JINMEI Tatuya / _-¾'BÆ'; '[EMAIL PROTECTED]'
Cc: '[EMAIL PROTECTED]'
Subject: RE: [dhcwg]
75 matches
Mail list logo
