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

From: "Dave Thaler" <[email-masked]>
Date: Wed, 9 Oct 2002 12:18:09 -0700

> From: Brian Haberman [mailto:[email-masked]]
> >> 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.

Why not?  Can you elaborate?
Shouldn't it always be true that if any two interfaces have the
same (non-link-local) subnet prefix, then their subnet-local
zone id MUST be the same?

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

I would disagree with that change.
 
> > 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.
> 
> 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.

I agree.  This also is what we implemented.

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

I agree with one important clarification.
"Explicitly configured" != "administratively configured".

The zero-config counter argument is a box that is labeled as 
having its default configuration be that interfaces are on the
same subnet different but different links (e.g. guaranteed 
to be different because they're different media, like an
802.11 access point with a wired Ethernet link).  Here
the explicitly configuration was done by the factory, not
by the admin.

-Dave 

--------------------------------------------------------------------
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, 09 Oct 2002 16:48:21 -0400

> zone id MUST be the same?

What happens to the zone ids when:

      1. Interface 1 has prefix1 and prefix2
      2. Interface 2 has prefix1 and prefix3
      3. Interface 3 has prefix2 and prefix4

> "Explicitly configured" != "administratively configured".

Totally agree.
> the explicitly configuration was done by the factory, not

Yep.

Brian

---

From: Robert Elz <[email-masked]>
Date: Fri, 11 Oct 2002 01:25:08 +0700

Date:        Wed, 9 Oct 2002 12:18:09 -0700
    From:        "Dave Thaler" <[email-masked]>
    Message-ID:  <[email-masked]>

It should be fairly obvious by now that I haven't yet read the
scoping-arch doc ...   Normally I wouldn't comment about something
I haven't read, my excuse is that that's not what I thought I was
doing here, I though I was commenting on the addr-arch-v3 doc,
which is the one in the subject...

That so much of this is turning on points related to the scoping-arch
doc, which isn't even a PS yet, suggests to me that:

  | > > 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)?
  | > 
  | > 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.
  | 
  | I would disagree with that change.

So would I.   The change I would make is to delete all references
of subnet-local from the addr-arch doc, and simply leave those values
as "to be defined" and then define them in the scoping-arch doc.

Sticking new stuff in docs, as they're in the process of going from PS
to DS is generally not proper, and while just defining a new number is
probably not going to be the kind of thing that would cause a problem,
doing so when there is no existing meaning for that number will just
lead to potential confusion.

That is, what happens if addr-arch is published as a DS, and even gets
to full std, with "subnet-local scope" in it, but the IETF never finishes
defining the subnet local stuff, and it eventually all just vanishes from
sight?

In 20 years, people will be wondering what this strange definition of
a subnet local scope, that has no meaning is all about.

Best is to remove it from the current doc, and place the definition
where it really belongs.   Let's not have the addr arch doc anticipate
what might come in the future,

  | The zero-config counter argument is a box that is labeled as 
  | having its default configuration be that interfaces are on the
  | same subnet different but different links (e.g. guaranteed 
  | to be different because they're different media, like an
  | 802.11 access point with a wired Ethernet link).

That's not a good example.   Remember the "link" we're talking
about here isn't a physical link - that idea vanished when repeaters
were first invented (which was just about the same time as ethernet).
A link for our purposes is the place where broadcast/multicast packets
will go, and that can certainly cross a wired/wireless ethernet boundary.
Not that it always will, but it certainly can, so "guaranteed to be
different" isn't the case there.

A better example would be a subnet made up of an ATM link and an
ethernet link (where the ATM is not running LANE).   Or to be more
perverse perhaps, an X.25 link and an ethernet link.   There, the
link level address formats differ, so they cannot possibly be same
link.  (There are plenty of other examples).

I'm not sure I'd expect to see many zeoconf boxes that fit this
"guaranteed to be different" kind of model ever actually appear.
So I'm not sure I'd be treating arguments about what they might do
very seriously.

I'm also not sure I really like the restrictions that seem to be
being proposed for subnet-local - they seem to blow away some of
the expectations I'd had for where and why I'd actually want to
use multi-link subnets (which certainly isn't as some kind of alternative
to bridging wireless and wired lans).

But I will wait until after I have actually read that draft before
I make comments about that.

kre

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 11 Oct 2002 13:01:52 -0400

>as "to be defined" and then define them in the scoping-arch doc.

This seems reasonable to me.

It moves this issue out of the IPv6 addr arch, allowing that document
to move ahead, and let's us work out the details in the scoped addr
arch and/or the multi-link subnets doc.

Good idea, Robert.

What do other folks think?

Margaret

---

From: Brian Haberman <[email-masked]>
Date: Fri, 11 Oct 2002 13:29:06 -0400

> What do other folks think?

I would go a step further.  Since almost no one has implemented the
routing/forwarding of scoped addresses (multicast & unicast site
locals), I recommend:

      1. Move all discussion of multicast scopes out of the addr-arch
         and into the scoped addr-arch doc
      2. Move all text on site-local unicasts out of the addr-arch
         doc and into the scoped addr-arch doc
      3. Add explicit text to the scoped addr-arch doc to define
         how/when/where these scopes should be used

This would allow the addr-arch doc to progress to DS without being
hung up on text involving scoped addresses but still describing the
pieces that we know work (e.g. global and link-local).  It would also
make a clean delineation between global and scoped addresses.

The scoped addr-arch doc can then be the home for future work on
scoped addresses.

My reasoning is based on actually having implemented scoped routing
and forwarding.  It is not trivial or for the weak of heart.

Brian

---

From: Rob Austein <[email-masked]>
Date: Fri, 11 Oct 2002 14:56:14 -0400

Both Robert's approach and Brian's approach seem workable.  Of the
two, I think Brian's approach is better, because it collects the
scoped address stuff in one place, which seems good on several counts.
--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Fri, 11 Oct 2002 14:58:53 -0400

> What do other folks think?

I think we need to all but deprecate scoped addresses except for
a few limited purposes such as autoconfiguration and disconnected
operation.   Trying to make them work in a general purpose fashion
places an untenable burden on hosts and applications.
--------------------------------------------------------------------
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: Bob Hinden <[email-masked]>
Date: Fri, 11 Oct 2002 14:34:41 -0700

>This seems reasonable to me.

To clarify this, I think the proposal is to change the definition of the 
multicast scope value 3 from "subnet-local scope" to "unassigned".  The 
table in section 2.7 Multicast Addresses would be changed to:

         scop is a 4-bit multicast scope value used to limit the scope of
         the multicast group.  The values are:

              0  reserved
              1  interface-local scope
              2  link-local scope
              3  (unassigned)
              4  admin-local scope
              5  site-local scope
              6  (unassigned)
              7  (unassigned)
              8  organization-local scope
              9  (unassigned)
              A  (unassigned)
              B  (unassigned)
              C  (unassigned)
              D  (unassigned)
              E  global scope
              F  reserved

Also, the definition of subnet-local multicast scope that follows would be 
removed.

If there is agreement to make this change, I could issue a new draft next 
week.  This should resolve the issue that Rob Austen raised.

Bob

---

From: Bob Hinden <[email-masked]>
Date: Fri, 11 Oct 2002 14:52:20 -0700

Brian,

I think this goes to far.  We have recently had a long discussion on the 
list regarding unicast site-local that concluded with keeping the 
definition of unicast site-local addresses in the document (see my email on 
21 Jun 2002, titled "Consensus on Site-Local Discussion").  Part of that 
was that we would add text to the Node Requirements document that nodes are 
only required to implement the rules specified in the default address 
selection document (now a Proposed Standard) and that there be no 
requirement that a node must be able to be part of more than one zone.

Bob

---

From: Brian Haberman <[email-masked]>
Date: Fri, 11 Oct 2002 18:05:50 -0400

Bob,
     What about all the multicast scopes?

     And will the new text in the Node Requirements document apply to
routers?  That is where many of the issues arise with site-locals.

     I won't even bring up the issues with DNS and site-locals.

     My point is that I believe that a clean separation should be made
between global addresses and scoped addresses.  We fully understand
how globals and link-locals work.  All the others are still being
hashed out.  If we make this break, the address architecture can
move along the standards track.  The (great amount of) additional
work that needs to be done on scoped addresses can be carried out
under the scoped address architecture.

Brian

---

From: Keith Moore <[email-masked]>
Date: Fri, 11 Oct 2002 19:06:31 -0400

> under the scoped address architecture.

actually I'd claim that we don't really understand how link-locals
work, at least not from the applications viewpoint.  but I enthusiastically 
support the idea of separating the work on globals from the work
on scoped addresses. 

Keith

---

From: Robert Elz <[email-masked]>
Date: Sat, 12 Oct 2002 21:11:57 +0700

Date:        Fri, 11 Oct 2002 18:05:50 -0400
    From:        Brian Haberman <[email-masked]>
    Message-ID:  <[email-masked]>

  |      What about all the multicast scopes?

Multicast scopes I'm not so sure about, but site local in general
should remain.   That works, and is defined just fine.

The issue with site local is deciding when it should be used, and
how one discovers the address, which has nothing at all to do with
the architecture of the addresses or their definition.  That is,
if you have such an address, and plan on using it, its properties
are quite clear.

kre

---

From: Brian Haberman <[email-masked]>
Date: Sun, 13 Oct 2002 17:31:54 -0400

Bob,
    I went back and re-read the thread you mention below.  There is
absolutely no reason why discussion of site-locals couldn't be moved
to the scoped addressing architecture doc.  It wouldn't affect the
text needed in the Node Requirements draft and it would put all the
scoped addressing discussion in one place.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Wed, 16 Oct 2002 10:49:25 -0400

Keith,

> support the idea of separating the work on globals from the work

I believe we do have a good understanding on how link-locals
work with utility protocols (ICMP, ND, MLD, routing protocols).
That is why the LL are needed in the base addressing architecture.
As for LL and user apps, I can't speak authoratively on the subject.

Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 16 Oct 2002 18:20:29 +0300 (EEST)

> support the idea of separating the work on globals from the work

Agree.

Consider a TCP session to a node which has fe80::1 assigned on two of its
interfaces, at least sounds potentially problematic.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: [email-masked]
Date: Thu, 17 Oct 2002 01:03:30 +0900

>As for LL and user apps, I can't speak authoratively on the subject.

	i believe we have some clues on application consideration to scoped
	addresses.  we may need to document this:
	- for numeric representation, scoped address notation, like fe80::1%if0
	  is available.
	- name-to-address mapping is rather complicated.
	  libc resolvers can sometimes deal with scoped address, assuming
	  (1) the API is scope-capable (getaddrinfo/getnameinfo), and
	  (2) the view of scope is the same, i.e. we don't cross node boundary
	  (3) all data paths are scope-capable.
	  for instance, /etc/hosts is ok.  DNS/NIS is not ok due to (2) and (3).
	  if server and client are on different machine view of scope is
	  different so (2) is not satisfied.  even if server is collocated with
	  client DNS uses 128bit notation (AAAA) so scope info is lost/not
	  handled so (3) is not satisfied.

	here are questions i can't really answer:
	- what is the exact relationship between link identifier and
	  interface names/identifiers (API issue)
		for instance, KAME assumes one-by-one mapping and uses interface
		identifier as link identifier.  but the assumption breaks if
		we consider configs like multiple interfaces connected to
		single ethernet broadcast domain
	- what defines a site
		there are theoretical definitions but operationally how?

itojun

---

From: Keith Moore <[email-masked]>
Date: Wed, 16 Oct 2002 15:44:34 -0400

addresses.

I don't get the sense that we have consensus on this, because some
people seem to think that scoped addresses are appropriate for use by
general-purpose apps.

for instance, there's really no way that an application can effectively use 
a scoped address in a referral to another host, since the app has no idea 
whether the host that uses the referral has access to the same scope as 
the party providing the referral.  name-to-address mapping is only one
instance of this problem.  

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 16 Oct 2002 15:45:34 -0400

> That is why the LL are needed in the base addressing architecture.

agree with this much.  I think it's much harder to justify SL.

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 16 Oct 2002 13:13:36 -0700

Keith Moore wrote:
> I don't get the sense that we have consensus on this, because 
> some people seem to think that scoped addresses are 
> appropriate for use by general-purpose apps.
> 
> the party providing the referral.  name-to-address mapping is 
> only one instance of this problem.  

An implementation note which identifies the need for any multi-party
apps to have a scope determination mechanism before using SL is
appropriate. Claiming SL is something that applications can't
effectively use is a bit over the top. For a simple 2 party app (like
sending a file to my printer), SL is a very appropriate addressing
mechanism. If I don't want the world to connect to my printers, it is
much easier to filter FEC0::/16 at the border than it is to list every
printer in an access control list.

A multi-party app developer should be happy there is a specific range of
addresses set aside for SL. Without that it becomes a guessing game as
to which addresses might work or not. With SL, the multi-party app can
clearly state that those will not be used, so the environment becomes
much clearer.

Tony

---

From: Keith Moore <[email-masked]>
Date: Wed, 16 Oct 2002 16:47:34 -0400

> appropriate. 

no, I'm sorry.  It's not.  it's insane.  

look, it's a separation of function argument.  the network's job is to 
do "best effort delivery" SO THE APPLICATION DOESN'T HAVE TO.  if you
expect applications to do routing and address selection and to know
about network topology not only on the local network but from the point
of view of distant peers just in order to get the packets delivered,
why don't we just dispense with routing protocols entirely?

> Claiming SL is something that applications can't

that's the same kind of bogus claim that's being made by the zeroconf
folks for v4 LL addressing. 

> to which addresses might work or not. 

it's a guessing game anyway if sites think that SL addresses can be used
as a substitute for routable addresses.

Keith

---

From: [email-masked]
Date: Thu, 17 Oct 2002 10:00:18 +0900

>instance of this problem.  

	agreed.  you can't pass around scoped address across nodes (in general)
	as the view of the scope differs between nodes.  i have clearer idea
	on link-locals, but i have almost no solutions against site-locals.
	there are security issues associated with it (attacking other company's
	inside machine using routing header w/ site-local address, and such...).

	scoped address complicates address in referral.  to give a concrete
	example, to support ftp session using scoped address, KAME ftpd
	behaves like below to deal with "EPRT" command:
	- control connection is using TCP over link-local address,
	  between fe80::2 (ftpd) and fe80::1 (client).  ftpd is seeing
	  some scope identification in sockaddr_in6 returned from getpeername/
	  getsockname.
	- ftpd receives an EPRT command, like "EPRT |2|fe80::1|9999|" from the
	  client (note that there's no scope identification in the FTP command
	  stream)
	- ftpd fills sockaddr_in6 with fe80::1
	- ftpd copies sin6_scope_id from the sockaddr_in6 for control
	  connection, ASSUMING that the address specified by EPRT is in the
	  same scope as the control connection.  these days the assumption
	  holds as EPRT to thirdparty address is disallowed, however, it is not
	  really a sane assumption to make.
	- ftpd makes data connection to fe80::1%<scope identification>,
	  which (hopefully) reaches the client.

itojun

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 17 Oct 2002 11:31:16 +0900

>>>>> On Thu, 17 Oct 2002 10:00:18 +0900, 
>>>>> [email-masked] said:

> 	inside machine using routing header w/ site-local address, and such...).

A tiny clarification (which is not directly related to the topic): the
attacker can't go inside the other sites using a routing header, as
long as the site border router is fully compliant to section 9 of
draft-ietf-ipngwg-scoping-arch-04.txt.  (Or perhaps you're assuming
the existence of a non-compliant border router.)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 23 Oct 2002 12:36:32 +0900

>>instance of this problem.  

	another example of complication due to the scoped address.
	(previous example was FTP)

	X uses xhost(1) to control accesses to X server.  For instance,
		% xhost +10.1.1.1
	would let X clients from 10.1.1.1 to access X server.
	xhost(1) itself is a X client.  therefore, it can be anywhere - it can
	talk with X server over the net.

	xhost(1) transmits the address (like 10.1.1.1 above) in binary form,
	so 32bit for IPv4.
	if we simply extend it to take 128bit IPv6 address, we cannot use
	scoped IPv6 address, because of two reasons:
	(1) scope identification will be stripped off when xhost(1) transmits
	    the address to X server (since the protocol does not pass scope
	    identification
	(2) even if we extend the protocol to pass around scope ID -
	    if the view of the scope differs between xhost(1) and X server
	    (i.e. xhost(1) and X server are on different node), it is not
	    possible for xhost(1) to deduce scope ID on X server.

	one possible solution would be to make xhost(1) transmit addresses
	as a string, and let X server decode it.  even so, the user of xhost(1)
	has to know the view of the scope on the machine running X server.

itojun

---

From: Robert Elz <[email-masked]>
Date: Wed, 23 Oct 2002 17:43:07 +0700

Date:        Wed, 23 Oct 2002 12:36:32 +0900
    From:        Jun-ichiro itojun Hagino <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	another example of complication due to the scoped address.
  | 	(previous example was FTP)

FTP in general is an interesting case to look at (though as people use
it in practice, with 3-way FTP prohibited, it turns out to be no different
than anything else), but ...

  | 	X uses xhost(1) to control accesses to X server.  For instance,
  | 		% xhost +10.1.1.1

isn't really interesting at all.   xhost is an administrative tool for
controlling the server.   Any addresses involved are clearly in the
context of the X server - they're used only to compare the source of
incoming connections.   Whether or not the address means anything, be
it the same thing or a different one, at the client (where the xhost
command is run), or nothing at all, is really irrelevant.

There's certainly an issue of translating names to addresses in the
context of the server, at some other location, but that's really the
only issue.

Where the X server lives only in one zone (or each scope) there's no
scoping issues at all really.  Where it lives in more than one, then
technically, one would want to allow the server to accept connections
from fe80:;1 in zone 1, but not fe80::1 in zone 2.   There's no way for
xhost to accomplish that (I expect, without looking at how X has been
extended to permit v6 addresses - if done properly, there would be room
there for a scope identifier) but this could just be added on as yet
another limitation of the xhost "authentication" mechanism - allowing
connections from one address, would also allow connections from other
clients that have the same address, in other zones that can reach the
X server.   Big deal .... xhost is trash that no-one who actually cares
about real access control of their X servers uses anyway.

  | 	one possible solution would be to make xhost(1) transmit addresses
  | 	as a string, and let X server decode it.  even so, the user of xhost(1)
  | 	has to know the view of the scope on the machine running X server.

Yes.   Anyone running xhost should understand the context of the X server.
That's beyond doubt, address scopes are just one more issue that needs to
be understood (and one more reason to discard xhost completely).

kre

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 Oct 2002 11:17:09 -0400

> incoming connections. 

xhost is based on the reasonable assumption that address space was shared
by the client and the server.   are you really claiming that you
expect mere *users* (not just hosts and apps) need to be to keep track 
of address scopes?
--------------------------------------------------------------------
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]
--------------------------------------------------------------------