Subject: RE: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt

From: [email-masked]
Date: Mon, 17 Feb 2003 18:09:54 +0200

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,
>     the prefix might be used for address configuration with some of
>     the addresses belonging to the prefix being on-link and others
>     being off-link."
> 
> Does this mean that prefix information options with the L bit not
> set can be used to auto-configure off-link global or site-local
> addresses?

Do you have some suggestion of text to add?

thanks,
John

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 17 Feb 2003 12:30:32 -0800

John,

> Do you have some suggestion of text to add?

Unfortunately no, because RFCs 2461 and 2462 are both ambiguous on
the subject. RFC 2461, section 6.3.4 ("Processing Received Router
Advertisements") says:

    Prefixes with the on-link flag set to zero would normally have the
    autonomous flag set and be used by [ADDRCONF].

But, [ADDRCONF] (i.e., RFC 2462) says nothing about how to handle
prefix options with the on-link flag ("L") set to zero!

I believe the Node Requirements document is the right place to resolve
the ambiguity; I'm just not sure what that resolution should be.

Fred
[email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Mon, 17 Feb 2003 22:17:58 -0500

> >>set can be used to auto-configure off-link global or site-local

No. The wording really does says what it is supposed to say. If the L
bit is is not set, one cannot say anything about whether the prefix is
on-link or off link. Specifically, a sender cannot assume that other
addresses covered by that prefix are on-link and send packets directly
to them; instead, packets for those destinations must be sent to a
router.

But it may (or may not) be the case that the destination is on the
same link as the original sender. If it is, the router will forward
the packet back to the same link. It may (or it may not) also send a
redirect to the sending node.

This is a feature that allows a router to arrange to have all traffic
forwarded to  it, even for destinations that are directly reachable.
It also (possibly) helps support things like multi-link subnets, where
some destinations may be on one link, but others on a different link,
but both covered by the same prefix.

> prefix options with the on-link flag ("L") set to zero!

The point is that if the bit is set, one assumes all destinations
covered by the prefix are on link. If it is not set, you can't assume
that and one does nothing.

> the ambiguity; I'm just not sure what that resolution should be.

Does the above explanation help? I.e., do you still believe there is
an ambiguity?

Thomas

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 18 Feb 2003 10:44:53 -0800

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 specified
in 5.5.3 d). But then, which link would one derive an interface identifier
from in order to form an address? (And, which interface would one assign
the address to?)

I believe this should be clarified somewere, e.g., in the IPv6 node reqt's
document. The challenge is in specifying something that is neither too
precise that it precludes legitimate functionality nor too broad that
it opens the door to security holes and/or misconfigurations. In particular,
if it's not OK for a node to configure an address from an advertised prefix
with the "L" bit not set we should probably say so somewhere and give some
rationale.

Regards,

Fred
[email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Fri, 21 Feb 2003 13:25:01 -0500

"Fred L. Templin" <[email-masked]> writes:

> in 5.5.3 d).

Good, as that is the intended behavior.

> But then, which link would one derive an interface identifier

This question applies to any address a node autoconfigures, regardless
of the setting of the L-bit. The scope of the advertisement of course
applies to the interface on which it receives.

It's not that surprising to me that the wording on the L-bit still
seems odd. My recollection is that the exact wording you have been
quoting was put in explicitely because the previous wording was even
more confusing. :-)

The whole point is that if the A bit is set, you do the processing
associated with generating an address. To do this, you don't need to
know whether the prefix is considered on-link or not. Likewise, the
list of prefixes to consider on-link is independent of any addresses
you may (or may not) have configured. They are two logically
orthogonal issues.

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).

Thomas

---

From: Bob Hinden <[email-masked]>
Date: Fri, 21 Feb 2003 11:14:29 -0800

>detail we're talking about here).

My view as well.

Bob

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 24 Feb 2003 10:01:50 -0800

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:

> applies to the interface on which it receives.

When you say that the scope of the advertisement applies to the interface
on which it receives, are you also implying that the scope of any addresses
autoconfigured from prefixes received in the advertisement apply to the
interface as well - regardless of the state of the "L" bit? Asked another
way, when a prefix option has the "A" bit set and the "L" bit NOT set,
should the address autoconfigured from the prefix be: a) assigned to the
receiving interface, b) treated as a node_ID independent of any of the
node's interfaces, or c) implementor's-choice?

Thanks,

Fred Templin
[email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Mon, 24 Feb 2003 16:40:43 -0500

Hi Fred.

> interface as well - regardless of the state of the "L" bit?

Yes.

> Asked another
> receiving interface,

Yes

> b) treated as a node_ID independent of any of the node's interfaces,

No.

> c) implementor's-choice?

No.

What wording would lead you to think to answer yes to b) or c)?  I'm
also puzzled that you would think that doing b) would make sense. In
most cases, it would not. The different interfaces will likely connect
to different links that have different subnet prefixes assigned to
them. It wouldn't make sense to assign an address on an interface that
the routers (or hosts) on that link wouldn't know were on that
link. 

Thomas