Subject: Node Requirements Issue 3

From: [email-masked]
Date: Thu, 24 Oct 2002 14:14:40 +0300

Hi all,

> 	3) How to support Site Local Addresses.

Brian Haberman said:

 A node is only required to support being in 1 site.  The issues with
 multi-sited nodes is too complex to make a mandatory feature.  By
 supporting 1 site, the node can treat the site local addresses as
 globals.

Bob Hinden said:

   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.

So, this means that:

	A node MUST support Default Address Selection.

	A node MUST support being in 1 site; MAY support being in more than one.

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: Keith Moore <[email-masked]>
Date: Thu, 24 Oct 2002 11:02:40 -0400

we'd be far better off to deprecate site local addresses, as nobody has
actually given a convincing case for their use.
--------------------------------------------------------------------
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: Pekka Savola <[email-masked]>
Date: Thu, 24 Oct 2002 18:14:56 +0300 (EEST)

> actually given a convincing case for their use.

I got the same hunch too, but first they'd have to be killed from addrarch 
revision, I believe -- or at least some wordings softened.

Site-local --> experimental ?

-- 
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: Ralph Droms <[email-masked]>
Date: Thu, 24 Oct 2002 11:23:20 -0400

In addition, my intuition is that we don't fully understand the impact and 
effect of site-local addresses on, for example, router configuration, DNS, 
addressing architecture, etc.

It would help if we had a document describing use cases and open issues 
that we could discuss...

- Ralph

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 24 Oct 2002 12:17:42 -0400

I think that we should keep site-local addresses in the
addressing architecture, but limit their use to non-globally-
connected IPv6 networks.

Margaret

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Oct 2002 13:28:43 -0400

> addressing architecture, but limit their use to non-globally-

the problem is that even a network that isn't connected directly to
the global internet may have nodes that communicate with other nodes
that are connected to the global internet (say through private connections
to other networks).  so the constraint you propose doesn't relieve apps 
of the need to be aware of site-locals and network topology.

site-locals would be okay for truly isolated networks.  the trouble is
getting people to understand that isolated really does mean not connected
to any other networks.  RFC 1918 wouldn't have caused so many problems 
if people had heeded the limitations imposed on its use.

Keith

---

From: Steven Blake <[email-masked]>
Date: 25 Oct 2002 16:08:16 -0300

> actually given a convincing case for their use.
	
Site locals as defined in draft-ietf-ipngwg-addr-arch-v3-10.txt are
functionally no different than RFC 1918 addresses for IPv4.

Long term, less chaos will result if a block of addresses is set aside
as "unregulated spectrum" than if folks start configuring prefixes out
of the ~73% of the address space that is currently unassigned.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake               <[email-masked]>
Ericsson IP Infrastructure                +1 919-472-9913

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 25 Oct 2002 15:40:30 -0400

>addressing architecture, but limit their use to non-globally-

Some folks have pointed out that it might have been helpful if
I had explained my reasoning...

The addressing architecture currently defines a set of addresses
that are allocated for use as "site-local unicast addresses", but
it does not discuss the details of when or how those addresses can
or should be used.

The scoped addressing architecture document defines how site-local
unicast addresses (and other scoped addresses) will be used, and
defines node behaviour related to these addresses.  I am suggesting
that we should consider placing some restrictions on the _use_
of site-local addresses in the scoped addressing architecture
document.

However, it is imperative that the site-local address allocation
remain in the addressing architecture, even if we do decide that
the use of these addresses should be restricted (or even forbidden).
The allocation has been there for several years, and there are some
implementations that recognize these addresses.

I also believe that it is apporpriate for the node requirements
document to indicate the minimal acceptable support that a node
should have for site-local unicast addressing.

In my opinion, we should limit the use of unicast site-local
addresses to non-globally connected sites, and have the following
requirements for IPv6 nodes:

         - Hosts do not have to be aware of site-local addresses
                 at all (treat them just like globals).
         - Routers do not have to be aware of site-local
                 addresses at all (treat them just like globals).

I do understand that, even if we do make this restriction, there may
be some people in the world who will later insist on using site-local
addresses (or other allocated private addresses) to build
a private address space within a globally connected IPv6 network.
I also understand that those people may build a kludge tower to
support this, similar to the IPv4 kludge tower needed to support
NAT, but with the added twist that a single node may have both
private and global addresses (yum!).  However, I don't think that
the IPv6 WG should go down the rat-hole of documenting that kludge
tower...

Instead, I think that we should advocate a position where all
nodes on globally attached networks have global addresses, and
site-local addresses are only used on non-globally connected
networks.  This would work with the currently documented IPv6
routing protocols, would provide the easiest IPv4->IPv6 transition
for applications, and would not require changes to DNS.  This also
has the advantage of limiting the problem that the IPv6 WG is trying
to solve, which should allow us to finish up the base IPv6 documents
and confidently deploy IPv6.

In my opinion, IPv6 does not require support for private
site-local unicast address spaces to be successful.  The major
benefits of IPv6 are a larger address space (which should eliminate
some motivations for using private address spaces) and host
autoconfiguration, and I think that the world is already preparing
to deploy IPv6 based on those current advantages.

I _would_ support an effort to start a separate IRTF or IETF WG
to explore whether we can build an architecturally sound model for
private and global addresses to co-exist on the same network
and in the same nodes, but I would prefer not to invent that
model in the IPv6 WG and build it into the core of IPv6.

This is my personal opinion, not a directive from the chairs or
anything like that.

Margaret

---

From: Brian Haberman <[email-masked]>
Date: Fri, 25 Oct 2002 16:01:53 -0400

Margaret,

> it does not discuss the details of when or how those addresses can

This is fine with me.

> of site-local addresses in the scoped addressing architecture

I agree.

> implementations that recognize these addresses.

Yes.

>                 addresses at all (treat them just like globals).

May I suggest that this behavior MUST be the default?  That way,
an administrator has to make a conscious decision to enable the
multi-sited feature.

> the IPv6 WG should go down the rat-hole of documenting that kludge

Completely agree.

> and confidently deploy IPv6.

Good.

> to deploy IPv6 based on those current advantages.

I would like to re-iterate that v6 does not need site-local
addresses to be successful.  To me, the benefit does not come
close to outweighing the cost.

> model in the IPv6 WG and build it into the core of IPv6.

Sounds reasonable to me.

> This is my personal opinion, not a directive from the chairs or

So, the synopsis is:

      1. FE80::/10 allocation stays in addr arch
      2. Text is added to the node reqs specifying single-site
          behavior as the default
      3. Text is added to the scoped addr arch to clearly define
         the use case for scoped addresses

What about text clarifying the issue with multi-link subnets in
addr arch?

Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 25 Oct 2002 16:30:31 -0400

>         the use case for scoped addresses

Yes, that sounds right to me.  With my added recommendation that
the use case for site-local should be to use them only on
non-globally connected networks.

>What about text clarifying the issue with multi-link subnets in

Bob has already submitted a new draft that removes the subnet-local
multicast code point and returns it to unspecified, as he proposed
on the list a week or two ago.  This resolved Rob Austein's
objection, and I don't think that anyone on the list objected
to the change.

If/when a proposal for multi-link subnets is adopted, that proposal
can define an appropriate multicast code point (if desired) and
define its use.

Margaret

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 Oct 2002 16:33:16 -0400

> functionally no different than RFC 1918 addresses for IPv4.

RFC 1918 addresses are intended only for isolated networks, with the 
only connections to the outside world to be provided by application 
level gateways.  

> of the ~73% of the address space that is currently unassigned.

It's not at all clear that RFC 1918 lessened the chaos caused by NAT.

Keith

---

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

> of site-local addresses in the scoped addressing architecture

that sounds reasonable.  at least we should say that site-locals
cause problems for some kinds of applications, we don't have
good solutions to those problems yet, and we discourage use of
site-locals until such problems are solved - and even then we don't
know how well they will work with apps that aren't aware of SLs.  

IMHO we should also make similar statements about link-locals.

> implementations that recognize these addresses.

I certainly don't want to make SL addresses available for other uses -
having them be labelled 'reserved for site-local use if we ever figure
out how to use them sanely' makes sense to me.

> addresses to non-globally connected sites, 

I think we should limit them to sites that aren't connected to
other IP networks using IP.  If host H1 is on a network N1 that 
uses site-locals, and host H2 is on a network N2 that connects 
to both N1 and the public Internet, then an app that employs
both H1 and H2 and perhaps other hosts on the Internet will have
problems dealing with SL addresses from N1.

> and have the following

also: Applications should not have to be aware of SL addresses at all
(just treat them like globals).

> the IPv6 WG should go down the rat-hole of documenting that kludge

right.  and we would do well to discourage that kludge tower, and 
also to identify better ways to solve the problems that  the kludge
tower was attempting to solve - easy renumbering (IPv6 is better but 
we're not there yet), efficient access via multiple providers
(there are lots of limitations with advertising multiple prefixes), 
security, privacy, ease of configuration, etc.
 
> networks.  

I don't think that's sufficient.  We need for all nodes on all
non-isolated networks to have global addresses.  It's becoming
increasingly common for private networks to interconnect to
other networks which may or may not be attached to the public
Internet.   We need for applications to be able to cope with 
operating across both private and public networks.  That doesn't
mean that such applications should route data between private 
networks and the public internet or between private networks
that don't explicitly connect to one another,  (e.g. the app 
shouldn't try to circunvent access controls). on the contrary,
the app should be able to trust the addresses to be globally unique
and to trust the network to be able to route packets from any
source to any destination if the network's policy permits.
unless the app is explicitly configured to do otherwise
(as in a proxy that permits limited access across a firewall), 
it shouldn't have to build its own addressing and routing system.

> This would work with the currently documented IPv6

sounds reasonable, provided such a WG or RT were populated 
with a healthy balance of layer 3 and layer 7 folks.

Keith

---

From: Alain Durand <[email-masked]>
Date: Fri, 25 Oct 2002 22:40:07 -0700

Margaret,

I think this is the right direction. Thank you for clarifying things.
Also I support Keith point on limiting SL to sites that do not have
a transitive connection to the Internet.

	- Alain.

---

From: Rob Austein <[email-masked]>
Date: Sat, 26 Oct 2002 02:17:38 -0400

I think that Margaret's proposal on site-local addresses makes a lot
of sense, and I think it's the best suggestion I've heard to date for
how we should move forward from where we are now on this issue.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------