Subject: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt

From: Rob Austein <[email-masked]>
Date: Wed, 02 Oct 2002 17:01:06 -0400

I made the mistake of allowing my arm to be twisted into reviewing
draft-ietf-ipngwg-addr-arch-v3-10.txt last week, and was sad to find
what appears to be an ambiguity in some of text that deals with
subnet-scope multicast.  Given that this document was already before
the IESG at the time I found this, I've been discussing this with our
AD, who brought in our WG chairs once he and I agreed that there might
be a problem here, but we felt that the discussion of what to do about
this really should take place out in the open on the WG mailing list.

So, what I said (after some initial clarifying discussion) was:

  In the absence of a precise definition of the distinction between a
  link and a subnet, it is unclear what a router should do with a packet
  addressed to a transient multicast address with subnet-local scope.
  Excerpting from the draft:

	       2  link-local scope
	       3  subnet-local scope
	       4  admin-local scope

	       ...

	       link-local and site-local multicast scopes span the same
	       topological regions as the corresponding unicast scopes.

	       subnet-local scope is given a different and larger value
	       than link-local to enable possible support for subnets
	       that span multiple links.

	       admin-local scope is the smallest scope that must be
	       administratively configured, i.e., not automatically
	       derived from physical connectivity or other, non-
	       multicast-related configuration.

  So subnet-local is a larger scope than link-local, and may be derived
  automatically from physical connectivity (in some completely
  unspecified way!).  So what should a router do with that packet?  To
  forward or not to forward, that is the question.

  One could address this concern by adding text (somewhere) to the
  effect that, until such time as a standards track document specifies
  how a router should determine what the subnet-scope boundaries are and
  what a router should do with an otherwise valid packet addressed to a
  multicast address with scop set to subnet-local, routers should handle
  such packets precisely as they would if scop were set to link-local.
  Or something like that.
--------------------------------------------------------------------
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: Brian Haberman <[email-masked]>
Date: Wed, 02 Oct 2002 17:35:37 -0400

Rob,
     The subnet-scope is delineated in the same manner as the scopes
6,7,8,9...  That is, a router maintains a scope zone id per interface.
So, if I have a router that has interfaces 1,2,3, & 4 and the admin
assigns a subnet-local scope zone id of 100 to interfaces 2 and 4,
then 2 and 4 are in the same subnet scope zone and multicast packets
received on one of those interfaces can only be sent to the other
interface with the same scope zone id.

     This is discussed in the Scoped Addressing Architecture in the
routing section.

Brian

---

From: Steve Deering <[email-masked]>
Date: Wed, 2 Oct 2002 15:07:55 -0700

>this really should take place out in the open on the WG mailing list.

As part of the AD/chair discussion, I responded to Thomas's report of
the issue as follows:

>To: Thomas Narten <[email-masked]>
>From: Steve Deering <[email-masked]>
>Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt
>Cc: Bob Hinden <[email-masked]>, Margaret Wasserman <[email-masked]>, Rob Austein <[email-masked]>, Erik Nordmark <[email-masked]>
>
>At 10:43 AM -0400 10/2/02, Thomas Narten wrote:
>>One last (??) issue on this document has popped up. The issue as I
>>understand it is that with the addition of subnet-local multicast
>>scope, the document leaves out details about how routers are supposed
>>to know what the actual subnet boundaries are.
>
>Thomas,
>
>Every router (whether IPv4 or IPv6) knows what subnets its own interfaces
>belong to (or, more accurately, what subnet numbers are assigned to
>the links to which it has interfaces).  That is the most basic
>configuration info provided to a router -- it is provided with that info
>in order to do unicast routing and forwarding.  To enforce subnet-local
>scope it is necessary simply to inhibit the forwarding of subnet-local-
>destined packets between interfaces that do not belong to the same subnet.
>I would have thought that would be obvious.  For those for whom it is not
>obvious, there is additional detail on the default configuration of
>scope zone boundaries in the scoped address architecture spec, along
>with lots of other info required to implement address scoping.
>
>More comments in-line below...
>
>>Rob Austein <[email-masked]> writes:
>>
>> > ...  Excerpting from the draft:
>>
>> >              2  link-local scope
>> >              3  subnet-local scope
>> >              4  admin-local scope
>>
>> > 	     ...
>>
>Note that the determination of the span of subnet-scope is an example of
>"automatic derivation from...other, non-multicast related configuration",
>as mentioned in the description of admin-local.
>
>>Here is a suggestion:
>>
>>1) change the wording of the subnet-local definition to say something
>>   like:
>>
>>              that span multiple links. By default, routers assume
>>              that subnet scope and link-local scope are equivalent.
>
>I think that such a change is unwarranted if it will mean even
>more delay in the approval and publication of the spec.  If you can
>handle it as a Note to the RFC Editor or something like that, then
>fine.  However, I have a few problems with your added sentence
>above: 
>
>    - it's odd to stick that little implementation note there in the
>      middle of the scope descriptions
>
>    - it should refer to nodes, not just routers
>
>    - your statement would not necessarily be true for routers that do
>      support multi-link subnets -- for the them, the default might be
>      *not* to assume that subnet-local and link-local scope are
>      equivalent.
>
>Here's an alternative to your sentence which bypasses those problems:
>
>         In the normal case of a subnet confined to a single link,
>         subnet-scope is equivalent to link-scope.
>
>>2) to the admin-local scope, tweak the wording to say something like:
>>
>>              admin-local and all larger scopes must be
>>              administratively configured, i.e., they are not
>>              automatically derived from physical connectivity or
>>              other, non-multicast-related configuration.
>>
>>Make sense?
>
>I don't object to that changed wording, but neither do I see the
>necessity of it.
>
>Steve

In a response to that message, Rob asked me if I had forgotten about
unnumbered point-to-point links.  I answered as follows:

>Yes, I did forget about them, but I think it's obvious how to handle them:
>they are not part of a subnet that exists on any other link, so subnet-
>scope multicasts would not be forwarded to or from an unnumbered link.

Steve

---

From: Rob Austein <[email-masked]>
Date: Wed, 02 Oct 2002 18:07:51 -0400

> interface with the same scope zone id.

The key phrase in your explanation is "the admin assigns".  The
addr-arch doc says "admin-local scope is the smallest scope that must
be administratively configured".  So which is it?
--------------------------------------------------------------------
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: Rob Austein <[email-masked]>
Date: Wed, 02 Oct 2002 18:11:25 -0400

> >scope multicasts would not be forwarded to or from an unnumbered link.

Assuming that one suspends disbelief about the whole multi-link subnet
thing in the first place, it's far from obvious to me that unnumbered
links aren't part of a subnet that exists on other links.

The most common use I've seen of proxy ARP in IPv4 has been to extrude
small numbers of IP addresses across PPP links.

My apologies for not answering the rest of Steve's message right now,
but my family is about to break down the door to my office because
they want to eat dinner now....
--------------------------------------------------------------------
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: Steve Deering <[email-masked]>
Date: Wed, 2 Oct 2002 15:55:51 -0700

>links aren't part of a subnet that exists on other links.

So which is it?  Either we're talking about the case where multilink
subnets are not employed (no need to believe in them), in which case
my statement holds.  Or we are venturing into the oh-so-scary land of
multilink subnets, in which case the routers know (are required to
know, in order to make unicast routing work) that they are extending
the span of a subnet across more than one link, possibly including
point-to-point links, so know which links are part of the same
subnet, and can therefore do subnet-scope boundary enforcement as
necessary.

What am I missing here?

>small numbers of IP addresses across PPP links.

Yes, proxy ARP is an (undocumented) special case of multilink subnetting.

Steve

---

From: Steve Deering <[email-masked]>
Date: Wed, 2 Oct 2002 16:08:34 -0700

>be administratively configured".  So which is it?

You omitted the full description:

Subnet-local scope is an example of automatic derivation from "other,
non-multicast-related configuration".

Specifically, you don't directly configure a router to know which
subnet-scope boundaries pass through it (as you must do with larger
scopes).  Rather, you (typically, manually) configure the router
with subnet info -- including, perhaps, enabling or disabling
multilink-subnet behavior -- as required for unicast routing, and
then you automatically derive subnet-scope boundary information from
that "other, non-multicast-related configuration".

Or saying it more concisely: you don't administratively configure
subnet scope; you adminstratively configure subnet info for unicast
purposes, and then automatically derive subnet scope from that.

Steve

---

From: Rob Austein <[email-masked]>
Date: Wed, 02 Oct 2002 21:42:52 -0400

> non-multicast-related configuration".
                       ^
                  administrative

> purposes, and then automatically derive subnet scope from that.

Fine, you don't do multicast configuration, you do non-muliticast
configuration and automatically derive the multicast configuration of
it from the non-multicast configuration.

The point, however, if you go back to my original message, is that the
text in the draft can also be read as saying that the router is
somehow supposed to deduce this bit of configuration from its physical
connectivity without any administrative configuration at all, which is
sufficiently nebulous that it could logic like "oh, I have an ethernet
interface and a firewire interface, and I just know that multi-link
subnets were invented to make my firewire interface happy, so set the
same scope ID on both of these interfaces and forward packets between
them."  Which (again suspending disbelief) would arguably be ok if
there were a specification for multi-link behavior that said to do
that, but there isn't, so the draft leaves some ambiguity about
whether certain packets should be forwarded or not.
--------------------------------------------------------------------
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: Brian Haberman <[email-masked]>
Date: Wed, 02 Oct 2002 21:17:20 -0400

> be administratively configured".  So which is it?

Ah, I missed that addition to the text.  But, the handling from a
forwarding and routing point of view is the same (via the settings
of the scope zone id).

As for the setting of the scope zone ids.  Those can be derived by
the prefix configuration on each interface.  If the prefixes on
interfaces 2 and 4 above are the same, the scope zone id will be
the same.

And I believe that Steve addressed the issue of unnumbered links in
a different message.

Regards,
Brian

---

From: Rob Austein <[email-masked]>
Date: Wed, 02 Oct 2002 22:14:01 -0400

> >      middle of the scope descriptions

The current text of that paragraph in the addr-arch document
introduces an ambiguity, so it seems like a reasonable place to try to
resolve that ambiguity.

> >    - it should refer to nodes, not just routers

Fair enough.  It's the router behavior that I'm worried about, but
your proposed change is both harmless and reasonable.

> >      *not* to assume that subnet-local and link-local scope are

Since there is as yet no standards track definition of a multi-link
subnet, this would amount to adding a normative reference that would
block publication of the addr-arch Draft Standard for quite a while.
I assume that nobody wants such a thing to happen (I certainly don't).

> >         subnet-scope is equivalent to link-scope.

Same problem: in what case is a subnet not confined to a single link,
and how do you describe that case without adding a normative reference?

> >I don't object to that changed wording, but neither do I see the

I think the intention here was to remove the (presumably accidental)
implication that configuration for anything smaller than admin-local
-could- be derived automatically from physical connectivity.
--------------------------------------------------------------------
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: Rob Austein <[email-masked]>
Date: Wed, 02 Oct 2002 23:40:06 -0400

At Wed, 2 Oct 2002 15:55:51 -0700, Steve Deering wrote:
> 
> Either we're talking about the case where multilink subnets are not
> employed (no need to believe in them), in which case my statement
> holds.

Right.

> Or we are venturing into the oh-so-scary land of multilink subnets,
> in which case the routers know (are required to know, in order to
> make unicast routing work) that they are extending the span of a
> subnet across more than one link, possibly including point-to-point
> links, so know which links are part of the same subnet, and can
> therefore do subnet-scope boundary enforcement as necessary.
> 
> What am I missing here?

A standards track specification for the latter case.

---

From: Robert Elz <[email-masked]>
Date: Thu, 03 Oct 2002 13:32:19 +0700

Date:        Wed, 2 Oct 2002 15:07:55 -0700
    From:        Steve Deering <[email-masked]>
    Message-ID:  <v04220805b9c11bd929d0@[171.71.119.37]>

  | >Every router (whether IPv4 or IPv6) knows what subnets its own interfaces
  | >belong to (or, more accurately, what subnet numbers are assigned to
  | >the links to which it has interfaces).  That is the most basic
  | >configuration info provided to a router -- it is provided with that info
  | >in order to do unicast routing and forwarding.  To enforce subnet-local
  | >scope it is necessary simply to inhibit the forwarding of subnet-local-
  | >destined packets between interfaces that do not belong to the same subnet.

If I have

	A --------- B --------- C

and A-B is prefix1::/64 and B-C is prefix2::/64 and prefix1 != prefix2
then subnet local multicast packets are not forwarded through B, right?

If I have

	A --------- B --------- C

and A-B is prefix3::/64 and B-C is prefix3::/64 (a multi-link subnet)
then subnet local multicast packets are forwarded through B, right?

And if I have

	A --------- B --------- C

And A-B is prefix1::/64 and prefix3::/64, and B-C is prefix2::/64 and 
prefix3::/64 (prefix1 != prefix2, prefix1 != prefix3, prefix2 != prefix3)
then subnet local multicast packets arriving at B are .....   ???

I also assume that the necessary two implementations of all of this, that
will allow a doc containing it to advance to DS have been documented in
the implementation report?

kre

---

From: Brian Haberman <[email-masked]>
Date: Thu, 03 Oct 2002 07:37:23 -0400

> then subnet local multicast packets are not forwarded through B, right?

Yes.

> then subnet local multicast packets are forwarded through B, right?

Yes.

> then subnet local multicast packets arriving at B are .....   ???

What is the source address of the subnet-local multicast address?
Section 9, bullet 2 in the scoped addressing architecture doc describes
the forwarding logic for this case.  If the packet was sourced out
of prefix3, it would be forwarded.  If it was sourced out of one of
the other prefixes, it would be dropped.

Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 06 Oct 2002 10:38:32 -0400

Hi Robert,

>then subnet local multicast packets arriving at B are .....   ???

You haven't provided the information that router B would use
to make that determination.

Is router B configured so that the subnet-local zone IDs of its
A-B and C-D interfaces are the same or different?

If they are the same, then the subnet-local scope encompasses both
links, and subnet-local packets will be forwarded. If they are different,
then subnet-local packets won't be forwarded.  This also applies to your
other examples.

The unicast addresses uses on those links are immaterial to the
decision of whether or not to forward subnet-local packets between
these two links.

Margaret

---

From: Robert Elz <[email-masked]>
Date: Mon, 07 Oct 2002 13:21:52 +0700

Date:        Sun, 06 Oct 2002 10:38:32 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | You haven't provided the information that router B would use
  | to make that determination.

Brian Haberman provided an entirely good enough answer (which also was
that there wasn't enough information, but with different missing info).

  | Is router B configured so that the subnet-local zone IDs of its
  | A-B and C-D interfaces are the same or different?

What subnet local zone id ?
I wasn't aware that such a thing existed?
If it did, it would have to be assigned, which would make subnet-local
multicast jump out of the category of "no special config required"
that is (I think rightly) claimed for it, wouldn't it?

  | The unicast addresses uses on those links are immaterial to the
  | decision of whether or not to forward subnet-local packets between
  | these two links.

Hmm ... that is exactly the opposite of what Brian said, and is also
contrary to what (little) I know about multicast forwarding.  Generally
that's done based upon the (unicast) source address of the packet (along
with the destination address, naturally).

kre

---

From: Brian Haberman <[email-masked]>
Date: Tue, 08 Oct 2002 07:46:35 -0400

> What subnet local zone id ?

A border router between subnet local zones will have subnet
zone ids assigned to each interface (see sections 5 & 6 of
draft-ietf-ipngwg-scoping-arch-04.txt).

> that is (I think rightly) claimed for it, wouldn't it?

Not necessarily.  This was covered in a previous thread, but it
is possible that a router could detect that a common prefix has
been assigned to multiple interfaces and set the subnet-local
zone id appropriately.

> with the destination address, naturally).

Section 9 of draft-ietf-ipngwg-scoping-arch-04.txt explicitly states
that when forwarding packets with a less than globally scoped
destination address, the scope of the source address and the incoming
interface zone id are taken into account.

Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 08 Oct 2002 07:58:11 -0400

>that there wasn't enough information, but with different missing info).

Well, I'll defer to Brian.  His source address explanation is cleaner
and more intuitive than my zone ID explanation.  It also has the benefit
that it matches what is in the addressing architecture document.

I'm not sure, though, that Brian's explanation is consistent with the
following line in the scoped address architecture:

"Each interface belongs to exactly one zone of each possible scope."

Based on Brian's explanation, it would seem like the interfaces of
router B are actually each in two subnet-local zones, and router B
is using the source address of received packets to choose between
them.  Brian?

Margaret

---

From: Brian Haberman <[email-masked]>
Date: Tue, 08 Oct 2002 08:16:00 -0400

> is using the source address of received packets to choose between

Good catch Margaret.  I should have noticed that the example given
actually violates the scoped addressing architecture doc.  The
forwarding logic is still correct, but you can only have, at most,
one zone id per scope per interface.  Otherwise you would have
overlapping scope zones.

Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 08 Oct 2002 12:19:44 -0400

>one zone id per scope per interface.  Otherwise you would have

Are you sure?

I originally began an answer to Robert's third example with something
like "this is an invalid configuration".  However, I realized that I
was mistaken.

Assuming that router B has support for multi-link subnets, Robert's
example is a valid configuration showing a subnet-local zone
that encompasses two links.

There is no requirement that all hosts within a given zone need
to configure addresses from (all of) the unicast prefix(es)
within that zone, or that all routers need to advertise the same
unicast prefixes on all interfaces within a given zone.  Is there?

The real question is this:

By default, if a router is configured to advertise the same prefix
on two interfaces, should the router assume that the two interfaces
are in the same subnet-local zone?  Should the router assume that
the two interfaces are on the same link (i.e. in the same link-local
zone)?

These are questions that need to be answered in the scoped address
architecture.

I think it would be a reasonable default for a router that is
configured with the same prefix on two interfaces to assume that
those interfaces are on the same link (same link-local zone), and
in the same subnet-local zone.

In other words, I think that routers should default to the
single-link subnet case, unless mutli-link subnetting has been
explicitly configured.

What do you think?

Margaret

---

From: Rob Austein <[email-masked]>
Date: Tue, 08 Oct 2002 12:47:24 -0400

> single-link subnet case, unless mutli-link subnetting has been

I agree.

---

From: Brian Haberman <[email-masked]>
Date: Tue, 08 Oct 2002 13:56:58 -0400

> like "this is an invalid configuration".  However, I realized that I

If the rule stands that an interface can have no more than one
zone id per scope, then it is invalid if we expect a subnet-local
zone id to automatically appear when a prefix is configured on
an interface.

So, going back to Robert's example:

     - A-B is prefix1::/64 and prefix3::/64
     - B-C is prefix2::/64 and  prefix3::/64
     - (prefix1 != prefix2, prefix1 != prefix3, prefix2 != prefix3)

As long as B has one subnet-local scope zone id per interface,
the forwarding logic I described will work.

You could make it work with multiple zone ids on an interface,
but the logic would require a complicated RPF check on the
source address in order to determine which zone id to use in
the forwarding decision.  I don't think I want to go there.

> that encompasses two links.

It is valid from the base architecture.  It is valid from the
scoping architecture if there is no more than one subnet-local
scope zone id.

> unicast prefixes on all interfaces within a given zone.  Is there?

Not that I know of.

> the two interfaces are on the same link (i.e. in the same link-local

The more I think about it, the more I realize that "automagically"
creating the subnet-local scope zone id isn't going to work.
Especially with multiple prefixes per interface.

> These are questions that need to be answered in the scoped address

I think the addressing architecture needs to address the comment
on automatically creating the subnet-local zone id.

> in the same subnet-local zone.

But if they aren't on the same link, forwarding could break.

> single-link subnet case, unless mutli-link subnetting has been

This is slightly different than assuming that the interfaces are
on the same link.  If the router treats them as unique prefixes,
then forwarding and routing should work.

Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 08 Oct 2002 20:36:26 -0400

>Especially with multiple prefixes per interface.

So, this would be consistent with the suggestion that we
change the Addr Arch document to list subnet-local and larger
scopes as administratively defined (instead of just admin-local
and higher)?

Another possibility is that we could default to a non-multi-link
subnet case and declare the default to be subnet-local scope
== link-local scope.

>on automatically creating the subnet-local zone id.

This might be somewhat difficult, since I don't think that the
concept of zone IDs is mentioned in the Addr Arch.

>But if they aren't on the same link, forwarding could break.

So, does this mean that routers can't automagically configure
link-local zone IDs, either?  I had always assumed that two links
with the same prefix would be in the same link-local zone.  Is
that an invalid assumption?

>then forwarding and routing should work.

How would routing and forwarding work?  If the router thinks that
it has two "unique" unicast prefixes that are both prefix1::/64, how
will it know where to send a packet to prefix1::1?  Without
explicit host routes (which is the solution that Steve preferred in
the multi-link subnet case), there is no way to know whether or
not to forward a packet to that address.

Margaret

---

From: Brian Haberman <[email-masked]>
Date: Wed, 09 Oct 2002 08:10:50 -0400

> scopes as administratively defined (instead of just admin-local

Yes.  Given the issues with magically setting the subnet-local
zone id when multiple prefixes are enabled on an interface I
would agree with that change.

Though, I would like to be able to do automatic configuration
of subnet zone ids if only one global prefix is configured
per interface. :)  That would be nice for the zero-config
router scenario using multi-link subnets.

> subnet case and declare the default to be subnet-local scope

We may need this as well.  Typically, the default behavior for
any less than global scope zone id is that all interfaces are
in the same zone.  I don't think we want that behavior with
subnet-local, it should default to being equivalent to link-local.

> concept of zone IDs is mentioned in the Addr Arch.

If the change is made that subnet-local must be administratively
configured, you don't need to mention zone ids in the addr arch.

> that an invalid assumption?

It is if you believe in multi-link subnets.  Otherwise, your
assumption works fine and my comment is invalid.  Now, do we
want to say (somewhere) that in order to identify multi-link
subnets:

      - the prefixes must match
      - the subnet zone ids must match

This would give us the ability to identify the link-local ==
subnet-local case from the subnet-local > link-local case.

> not to forward a packet to that address.

Host routes would work.  Another possibility (though I haven't
thought it all the way through) would be to utilize NDP by sending
out NS's on both interfaces.  This doesn't work if prefix1::1
exists on both nets.

Brian