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
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
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 List
"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 confi
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
> 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
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 th
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:
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,
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 h
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 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 o
John,
[EMAIL PROTECTED] wrote:
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 th
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,
> 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
> > 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 p
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 mandator
> 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 ha
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
re
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 pr
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
> 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
[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
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 addresses
>when it is connect
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
state
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 tha
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 rou
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 warnin
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 wan
[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
scale
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
> scale deployment
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?
>
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 th
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]
---
[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
To: Loughney John (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 con
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
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
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 r
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 n
40 matches
Mail list logo