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]
; Loughney John (NRC/Helsinki)
Cc: Bound, Jim; [EMAIL PROTECTED]
Subject: Re: draft-ietf-ipv6-node-requirements-01.txt
There may be some additional discussion about the 'M' and 'O'
bits during
my slot in the ipv6 WG meeting Thu AM.
- Ralph
At 12:09 PM 11/21/2002 +, Greg Daley wrote
: ext Ralph Droms [mailto:[EMAIL PROTECTED]]
Sent: 21 November, 2002 14:56
To: Greg Daley; Loughney John (NRC/Helsinki)
Cc: Bound, Jim; [EMAIL PROTECTED]
Subject: Re: draft-ietf-ipv6-node-requirements-01.txt
There may be some additional discussion about the 'M' and 'O'
bits during
my slot
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
Hi Minto,
what do u meant say? Multihomed host is beyond this document?
What I mean is that it is not a requirement that an IPv6 Node
be multihomed.
is Running the routing protocol or necessary configuration
not a minimum requirement of multihomed host?
A multihomed host is not
PROTECTED]
Subject: RE: draft-ietf-ipv6-node-requirements-01.txt
Hi Minto,
This does not sound like a minimum requirement for IPv6 nodes - are you
proposing that IPv6 thermometer would need multihoming? The current
document does not state this is the maximum functionality for an IPv6
node
,
passive IPv6 node : thermometer, lighting, washer, refrigerator, some
kinds of home appliances
Daniel
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 17, 2002 10:09 PM
To: [EMAIL PROTECTED]
Subject: RE: draft-ietf-ipv6-node-requirements-01.txt
Hi Daniel,
4.5.5
In what cases will stateless address autoconfiguration fail? If it
fails, there is always the possibility of setting addresses by user
interaction
(typing in the addresses). Stateful is dependent upon DHCPv6, and
users cannot depend that it will be implemented everywhere, especially
since it is
not to use such terms.
John
-Original Message-
From: ext Soohong Daniel Park [mailto:[EMAIL PROTECTED]]
Sent: 18 December, 2002 01:51
To: Loughney John (NRC/Helsinki)
Cc: [EMAIL PROTECTED]
Subject: RE: draft-ietf-ipv6-node-requirements-01.txt
I am interested in home network
On Wed, 18 Dec 2002, Soohong Daniel Park wrote:
Basically, stateful address autoconfiguration is more useful than typing
in the addresses.
Because IPv6 address is far more complex.
Useful for who?
I certainly find typing addresses much more useful.
Many IPv6 addresses are very easy to
[EMAIL PROTECTED] wrote:
Hi Jari,
Thanks for the summary, I agree with you. Just a general note,
the Node Requirements document cannot specify new behavior
for IP security, I think it would be useful to have some work
get started to review and update this info.
There is ongoing work:
-
I agree with the comments. That section needs a rewrite. A couple
of points I wanted to raise, however:
- In this document, we want to describe the situation as it is in
the other RFCs. For instance, if the IPsec RFCs say you must
support AH and ESP then we say it here too. If the situation
[EMAIL PROTECTED] wrote:
Suggestions always welcomed.
I quite liked the text in the final LCNA draft. But it clearly doesn't
meet the requirements Jari covered in his post.
Richard.
IETF IPng Working Group Mailing List
Thanks for that, it certainly explains a bit. Can I suggest that in the
re-write these considerations are made more explicit.
Richard.
Jari Arkko wrote:
I agree with the comments. That section needs a rewrite. A couple
of points I wanted to raise, however:
- In this document, we want to
Thanks for pointing this out Richard. I agree with you. I (and at least one
more guy I know) had the same confusion. We could not figure out what the
whole section meant :-(
ext Richard Nelson wrote:
I've read this a couple of times and I find the security section (sec 8)
quite confusing. I
Hi Gupta,
Thanks for pointing this out Richard. I agree with you. I (and at least one
more guy I know) had the same confusion. We could not figure out what the
whole section meant :-(
The security section needs a re-write. Some of the confusion on the section
is due to the fact that it was
I've read this a couple of times and I find the security section (sec 8)
quite confusing. I am not a security expert but it appears to me that
it is not consistent.
In particular sec 8.2 says AH [RFC-2402] must be supported. It then
goes on to say there is no real need for AH and in both
it
in the first place. Ben Franklin]
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 20, 2002 7:52 PM
To: Bound, Jim; [EMAIL PROTECTED]
Subject: RE: draft-ietf-ipv6-node-requirements-01.txt
Hi Jim,
Today in v6ops I think I heard
There may be some additional discussion about the 'M' and 'O' bits during
my slot in the ipv6 WG meeting Thu AM.
- Ralph
At 12:09 PM 11/21/2002 +, Greg Daley wrote:
Hi Jim,
I find it hard to tell if you mean it is wrong (incorrect) or
wrong (not the right way to go).
about the current
Today in v6ops I think I heard that compliance to the ND M bit being set
is optional. That I think is wrong. But the node reqs doc states that
dhcpv6 is unconditionally optional which is probably correct because
stateful may not imply dhcpv6 today. But if the M bit is set the host
node (non
Hi Jim,
Today in v6ops I think I heard that compliance to the ND M bit being set
is optional. That I think is wrong. But the node reqs doc states that
dhcpv6 is unconditionally optional which is probably correct because
stateful may not imply dhcpv6 today. But if the M bit is set the host
Hi Jim,
I find it hard to tell if you mean it is wrong (incorrect) or
wrong (not the right way to go).
about the current status though,
section 5.4.5 of RFC 2462 mentions that a node which receives the
M flag goes should undertake stateful address configuration.
there is no MUST
56 matches
Mail list logo
