Thomas et al,
The main message I am getting is that the L bit is a don't-care from
the standpoint of RFC 2462 section 5.5, and I agree that that point needs no
further clarification. But, I'm still a bit uncertain on the following point:
Thomas Narten wrote:
This question applies to any address a
Hi Fred.
The main message I am getting is that the L bit is a don't-care from
the standpoint of RFC 2462 section 5.5, and I agree that that point needs no
further clarification. But, I'm still a bit uncertain on the following point:
Thomas Narten wrote:
This question applies to any address
Fred,
I'm still of the opinion that some ambiguity exists. Namely,
if a prefix option has the Autonomous flag (A bit) set and
the on-link flag (L bit) NOT set, one could infer from
reading RFC 2462, section 5.5 that it is OK to go ahead and
configure an address from the (off-link) prefix
Fred L. Templin [EMAIL PROTECTED] writes:
I'm still of the opinion that some ambiguity exists. Namely, if a prefix
option has the Autonomous flag (A bit) set and the on-link flag (L bit)
NOT set, one could infer from reading RFC 2462, section 5.5 that it is OK
to go ahead and configure an
I still do not (yet) see the need for further clarifications in the
documents (and certainly not in node requirements, for the level of
detail we're talking about here).
My view as well.
Bob
IETF IPng Working Group Mailing
Thomas,
I'm still of the opinion that some ambiguity exists. Namely, if a prefix
option has the Autonomous flag (A bit) set and the on-link flag (L bit)
NOT set, one could infer from reading RFC 2462, section 5.5 that it is OK
to go ahead and configure an address from the (off-link) prefix as
Fred,
I have myself been confused by the L bit in the past but I don't think
there is anywhere near as much ambiguity here as you. And, if there is
the node requirements document isn't the place to fix it.
I'm still of the opinion that some ambiguity exists. Namely, if a prefix
option has
Tim,
Tim Hartrick wrote:
Fred,
I have myself been confused by the L bit in the past but I don't think
there is anywhere near as much ambiguity here as you. And, if there is
the node requirements document isn't the place to fix it.
I'm still of the opinion that some ambiguity exists. Namely,
Fred,
Right now, all RFC 2462 (section 5.3.3) says is to go ahead and configure
addresses for prefix options with the A bit set; the L bit is don't-care.
But, RFC 2461 (section 6.3.4) says that a prefix information option with the
on-link flag set to zero conveys no information
Tim,
Tim Hartrick wrote:
Sure, that is what assigning an address to an interface means. Are you saying
that you want to send datagrams that are destined to an address which is
assigned to a local interface, to a router, just because the advertised prefix
from which the address was derived had
On Tue, 18 Feb 2003 13:56:36 -0800,
Fred L. Templin [EMAIL PROTECTED] said:
I have myself been confused by the L bit in the past but I don't think
there is anywhere near as much ambiguity here as you. And, if there is
the node requirements document isn't the place to fix it.
I'm still
Hi Fred,
I wonder if the setting of the L bit in Prefix Information options
also bears some mention in this section. RFC 2461, section 4.6.2 says:
When (the L bit is) not set, the advertisment makes no statement
about on-link or off-link properties of the prefix. For instance,
Fred L. Templin [EMAIL PROTECTED] writes:
I wonder if the setting of the L bit in Prefix Information options
also bears some mention in this section. RFC 2461, section 4.6.2 says:
When (the L bit is) not set, the advertisment makes no statement
about on-link or off-link properties of
On Mon, 10 Feb 2003 10:34:56 -0800,
Fred L. Templin [EMAIL PROTECTED] said:
I wonder if the setting of the L bit in Prefix Information options
also bears some mention in this section. RFC 2461, section 4.6.2 says:
When (the L bit is) not set, the advertisment makes no statement
It should be SHOULD. The M bit means use Tasteful. The O bit
means
use Stateful. Two different contexts. I was here when they were put
in
ND and recall why. One reason is that not everyone believed that just
stateless was acceptable and that was vision on those persons part.
We had a
I agree with this and think that a MUST for stateless and MAY for DHCP is
fine.
Bob (with no hats on)
We had a conclusive discussion off this point during the interim WG
meeting in Sunnyvale. The reasoning goes as follow: if we want to
maximize interoperability, we want to have a single
It should be SHOULD. The M bit means use Tasteful. The O bit
means
use Stateful. Two different contexts. I was here when
they were put
in
ND and recall why. One reason is that not everyone
believed that just
stateless was acceptable and that was vision on those persons part.
John,
It should be SHOULD. The M bit means use Tasteful. The O bit means
use Stateful. Two different contexts. I was here when they were put in
ND and recall why. One reason is that not everyone believed that just
stateless was acceptable and that was vision on those persons part. The
Roy et al,
I wonder if the setting of the L bit in Prefix Information options
also bears some mention in this section. RFC 2461, section 4.6.2 says:
When (the L bit is) not set, the advertisment makes no statement
about on-link or off-link properties of the prefix. For instance,
the
[EMAIL PROTECTED] wrote:
Ralph,
Not knowing the background of all readers of the doc, it
might be good to put your explicit warning in the text:
An IPv6 node that does not include an implementation of DHCP will be
unable to obtain any IPv6 addresses aside from link-local
Not knowing the background of all readers of the doc, it might be good
to
put your explicit warning in the text:
An IPv6 node that does not include an implementation of DHCP will be
unable to obtain any IPv6 addresses aside from link-local addresses
when it is connected to a link
Roy - thanks for noticing the omission of manually configured
addresses. Your revised text looks fine to me.
- Ralph
At 11:07 AM 2/7/2003 -0500, Roy Brabson wrote:
Not knowing the background of all readers of the doc, it might be good
to
put your explicit warning in the text:
An IPv6
Brian E Carpenter wrote:
Brian Haberman wrote:
[EMAIL PROTECTED] wrote:
Hi Ralph,
The text looks really good, what do other thinks? Does anyone
have a preference for Stateful Address Autoconfiguration to be
a SHOULD or a MAY?
I tend to agree with the SHOULD. Since these nodes recognize
Brian Haberman wrote:
Brian E Carpenter wrote:
Brian Haberman wrote:
[EMAIL PROTECTED] wrote:
Hi Ralph,
The text looks really good, what do other thinks? Does anyone
have a preference for Stateful Address Autoconfiguration to be
a SHOULD or a MAY?
I tend to agree with the
[EMAIL PROTECTED] wrote:
Hi Brian(s);
My concern is the scenario where an operator knowingly disables
prefix advertisements and enables DHCPv6. If the nodes doesn't
do DHCP, it is stuck with only the link-local address.
Understood. That certainly deserves a health warning. But in large
Hi all!
I support the proposal below the idea having DHCPv6 support as a MAY.
Best Regards,
-Juha W.-
-Original Message-
From: ext Jari Arkko [mailto:[EMAIL PROTECTED]]
Sent: 06 February, 2003 15:15
In general, stateless address autoconfig is a good thing, so we want
Jari Arkko wrote:
[EMAIL PROTECTED] wrote:
Hi Brian(s);
My concern is the scenario where an operator knowingly disables
prefix advertisements and enables DHCPv6. If the nodes doesn't
do DHCP, it is stuck with only the link-local address.
Understood. That certainly deserves a health
Jari,
At 03:14 PM 2/6/2003 +0200, Jari Arkko wrote:
[snip]
Maybe the right thing is to attach a warning or an explanation
about the implications and leave the support as a MAY. For
instance,
Nodes that do not implement DHCP may become unable to
communicate outside the link when their
Ralph, your text is fine. I didn't realize you already
had it there. Anyway, as long as a note roughly with
the contents we have been discussing appears, I'm OK
with it...
Jari
Do you suggest this text in addition to or replacing the following text
from my original draft:
An
IPv6 node
Jari - I liked the way your text was explicit about the consequences of not
obtaining a global address through DHCP when no stateless autoconfig
prefixes are advertised:
Nodes that do not implement DHCP may become unable to
communicate outside the link when their routers advertise
John,
I've reviewed the text in draft-ietf-ipv6-node-requirements-02.txt, and I
have some comments about the text concerning DHCP.
Regarding the use of DHCP for address assignment...RFC2462 is somewhat
vague about the requirement - there are no RFC2119 words guiding the ues of
DHCP in section
Ralph Droms wrote:
John,
I've reviewed the text in draft-ietf-ipv6-node-requirements-02.txt, and
I have some comments about the text concerning DHCP.
Regarding the use of DHCP for address assignment...RFC2462 is somewhat
vague about the requirement - there are no RFC2119 words guiding the ues
(NRC/Helsinki)
Cc: [EMAIL PROTECTED]
Subject: RE: M O Bits was: draft-ietf-ipv6-node-requirements-01.txt
John,
I've reviewed the text in
draft-ietf-ipv6-node-requirements-02.txt, and I
have some comments about the text concerning DHCP.
Regarding the use of DHCP for address
[EMAIL PROTECTED] wrote:
Hi Ralph,
The text looks really good, what do other thinks? Does anyone
have a preference for Stateful Address Autoconfiguration to be
a SHOULD or a MAY?
I tend to agree with the SHOULD. Since these nodes recognize the
'M' 'O' bit-settings, they should be capable of
In your previous mail you wrote:
following text :
4.5.5 Stateful Address Autoconfiguration
Stateful Address Autoconfiguration SHOULD be supported. DHCP
SHOULD or MAY?
= I agree, a MAY is enough.
[EMAIL PROTECTED]
Ralph,
I don't think that this was discussed completely last IETF. I was wondering
if you could suggest some text for the current Node Requirements doc?
thanks,
John
-Original Message-
From: ext Ralph Droms [mailto:[EMAIL PROTECTED]]
Sent: 21 November, 2002 14:56
To: Greg Daley;
John - the earlier discussions in the ipv6 WG meeting ran long, so we
didn't get a chance to discuss draft-droms-dhcpv6-issues-00.txt, which
includes some text on the 'M' and 'O' bits.
Anyway, I'll be travelling for the next couple of days. I'll review the
text in question and post some text
Hi Ralph,
John - the earlier discussions in the ipv6 WG meeting ran long, so we
didn't get a chance to discuss
draft-droms-dhcpv6-issues-00.txt, which
includes some text on the 'M' and 'O' bits.
I understand about that.
Anyway, I'll be travelling for the next couple of days. I'll
38 matches
Mail list logo
