Subject: I-D ACTION:draft-hinden-ipv6-global-site-local-00.txt

From: [email-masked] (by way of Bob Hinden <[email-masked]>)
Date: Mon, 09 Dec 2002 08:59:41 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: IPv6 Globally Unique Site-Local Addresses
	Author(s)	: R. Hinden
	Filename	: draft-hinden-ipv6-global-site-local-00.txt
	Pages		: 7
	Date		: 2002-12-6
	
This internet draft describes a proposal for IPv6 Globally Unique
Site-Local Addresses.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hinden-ipv6-global-site-local-00.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-hinden-ipv6-global-site-local-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-hinden-ipv6-global-site-local-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-hinden-ipv6-global-site-local-00.txt

<ftp://ftp.ietf.org/internet-drafts/draft-hinden-ipv6-global-site-local-00.txt>

--------------------------------------------------------------------
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: Alain Durand <[email-masked]>
Date: Mon, 09 Dec 2002 14:10:31 -0800

This proposal is making the assumption that MAC addreses are somehow stable.
I think this is a bad idea.
A simple change of a NIC card in a router will start a renumbering event,
and, although somehow simpler than in IPv4, IPv6 renumbering event are far
from painless.

On our servers, we recommend not to use staleless autoconfiguration based
on MAC addresses, but instead to use a locally administered token as 
interface ID.
Actually, our experience shows that in our environment, IPv4 addresses
are far more stable than MAC addresses.

- Alain.

---

From: Bob Hinden <[email-masked]>
Date: Mon, 09 Dec 2002 15:00:09 -0800

Alain,

>I think this is a bad idea.

MAC addresses are stable.  What may not be stable is their life in on an 
interface in a specific machine.  The words in the draft are:

    3.2 Assignment

    The globally unique site-local prefixes defined in this document are
    intended to be manually assigned to router interfaces in a site.  The
    global token used in each prefix would be created from an EUI-48
    address found in an interface on the subnet.

There is no requirement that this be the same as the routers interface nor 
is it required to be automatic.

MAC addresses were selected as a source of global token because they are 
good global token.

Bob

---

From: Alain Durand <[email-masked]>
Date: Mon, 09 Dec 2002 15:17:23 -0800

Bob Hinden wrote:

> There is no requirement that this be the same as the routers interface 
> nor is it required to be automatic.
>
> MAC addresses were selected as a source of global token because they 
> are good global token.

They are good global token, but they are tied to a particular piece of 
hardware
that might not be present in the same place in the network tomorrow morning.

And the process has to be somehow automatic, if not, what will happen if 
I (manually)
derived a prefix from one of the MAC adddresses on my router,
and one day I sell that router to someone else who is going to do the 
same thing?

- Alain.

---

From: Tim Chown <[email-masked]>
Date: Mon, 9 Dec 2002 22:58:32 +0000

Another issue is that certain quad fast ethernet vendors (e.g. Sun) 
make 4-port cards where each interface has the same MAC address, 
which would mean I assume that by default each of the subnets run off 
those ports would have the same /64 network prefix?

The DLink 570TX quad cards we use don't do that, but I think it may be
common enough to be an issue?

Possibly also revealing vendor equipment in a network by using the MAC
address in the prefix is not ideal?

My view on stateless autoconfiguration on servers is that it may be a gain 
in terms of being hidden from port scanning (as opposed to using 
prefix::1,::2,etc for servers).  But if you know the vendor make, the 
scanning may be down to 2^24 hosts from 2^64 (still a big space), and in
a lab of new equipment, the host IDs may be quite close if the network
cards came in a batch.  Just picking a "random" host part is probably the 
best compromise; use that 2^64 space :)

Tim

---

From: Mark Smith <[email-masked]>
Date: 10 Dec 2002 12:54:36 +1100

Hi Bob,

A few thoughts / questions / comments on your draft :

3.0 Proposal & 3.1 Global Token

* 8 bit areas 

I'm curious as to why you chose to allocate 8 bits for the area.

Allocating 6 bits for area would allow aggregation to take place on the
/16 bit boundary. I think this would make it a easier for network admins
to manage their site-local area prefixes when bounded at /16.

I was going to suggest putting back the u and g bits, which would make
connecting to the origin router for this prefix easier (just telnet to
fec0 + EUI-64 + EUI-64), but then realised that your site local global
token is generated from an EUI-48 :-(

I think there probably is some value in keeping the full EUI-48 as the
global token for trouble shooting reasons, at the sacrifice of 2 area
bits.

3.2 Assignment

* maybe be a bit more explicit about how manual configuration is
achieved.

I agree with and understand the motivation for manual assignment of
these prefixes.

However, the whole proposal has a strong "auto-configuration" theme -
deriving site-local addresses from EUI-48s sounds a lot like something
that would be done automatically by default.

Would a typical implementation of this manual assignment be a toggle
switch / [on / off] configuration option within a router ?

If so, additional text suggesting that these prefixes will be
automatically generated, but manually enabled / disabled (defaulted to 
disabled) might help overcome the "auto-configuration" theme of the
generation of these prefixes.

* the term "area" might be a bit vague, in the sense that usually people
talk about "areas", they are referring to OSPF areas.

I found when I initially read this term, I immediately wondered whether
this field has some use or value wrt OSPF.

A different name for this field might be a bit less confusing.

- I don't feel that strongly on this, I think it is just that "area" is
in such common usage in the OSPF context (and to my knowledge, no where
is in IP routing / addressing), most people would immediately associate
any usage of the term "area" in an RFC with OSPF.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Dec 2002 11:06:08 +0100

For the record, I am still completely against any proposal
that takes over the normal 16 bit subnet field, i.e.
generates a prefix longer than /48. It just isn't 
operationally convenient.

  Brian

---

From: Andrew White <[email-masked]>
Date: Thu, 12 Dec 2002 09:52:26 +1100

> operationally convenient.

I'm still unsure about this insistence on /48 as a critical point of
allocation.  /64 as a critical makes sense, as it is configured as the
changeover from subnet allocation to host allocation (for unicast addresses
at least).

But as for /48, consider these examples:

My home (say 4 subnets) is given a /48 for my SOHO network.
The local university (say 100 subnets) is given a /48 for the campus.
Multinational X (say 5000 subnets) is given a /48 for their entire VPN.

Only one of the above needs anything like a /48.

Next example, let's consider inside multinational X.  I want to allocate
subnets to sites.  /48 is our standard allocation, right?  But I can't
allocate /48s, because /48 is the allocation for the entire VPN, so I
instead allocate something smaller (probably a /56).

Now let's assume that said site wants to create a site-local network (not
sure why, since they're 'permanently' connected, but let's run with it). 
Why is the number /48 somehow magical for this site, considering they have a
/56 delegation?  All they really want is a way of generating internal /64
subnets.

/64 marks a well defined physical entity: the subnet, although even that can
be redefined if the address allocator wishes it.

/48 is a convenient mark for a logical entity: the 'end-user' network.  In
practice, these vary radically in size and may be further subdivided, so /48
is merely a useful convention.

-- 
Andrew White                [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Wed, 11 Dec 2002 19:12:11 -0500

> allocation.

renumbering is a lot more painful if you're trying to renumber
between prefixes of different lengths.
--------------------------------------------------------------------
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: Thu, 12 Dec 2002 16:14:29 -0800

Mark,

>global token for trouble shooting reasons, at the sacrifice of 2 area

I was trying to see how many bits I could have left over and still use the 
EUI-48 as the basis for the global token.  I think I agree that it would be 
simpler just using the whole 48-bits and shrink the area.

>that would be done automatically by default.

I agree.  I think one of the good things about this approach is that could 
be made to auto-configure the subnets.  I wasn't attempting to solve all of 
the issues to make that work in this draft.

>generation of these prefixes.

I agree adding some text to clarify how this could work would make it 
clearer.  Semi-automatic might be a good way to describe it.  The 
administrator could be give a choice of creating a prefix based in the 
interfaces EUI-48 address, enter a global token, or use a prefix it has 
heard advertised from another router.  This would make the installation of 
the routers fairly simple and in most cases avoid typing in big strings of 
digits.

>this field has some use or value wrt OSPF.

The use of area was not coincidental.  I was thinking about OSPF areas as 
that is probably about the right size to flat route a number of subnets.

>any usage of the term "area" in an RFC with OSPF.

Another question is the area field that useful or would it be better to 
just have /64 prefixes and flat route them in a site.  This might make the 
proposal simpler and better.  On the other hand, it is nice to have a way 
of scaling the routing protocol inside the site.

Thoughts?

Bob

---

From: Bob Hinden <[email-masked]>
Date: Thu, 12 Dec 2002 17:11:40 -0800

Keith, Brian,

>between prefixes of different lengths.

Ignoring the area field (that I am starting to think was a mistake) for a 
minute, the idea in the draft is that one could have site-local prefixes 
that are independent from the global prefixes and would not have to be 
renumbered.  Because they are globally unique they would survive site 
joining and/or splitting, change of ISP, change of topology, etc.  There 
were not intended to be used in the same manner as the global prefixes that 
have a 16-bit subnet field.

The cost for this flexibility was that they had to be flat routed in the 
site.  I think that is a good tradeoff, but opinions will vary.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Dec 2002 10:49:12 +0100

> between prefixes of different lengths.

Exactly. And we agreed a long time ago on /48 as the normal
(but not architecturally required) prefix length for every site,
except for degenerate /64 sites with no subnetting.

  Brian

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Dec 2002 12:14:28 -0500

> renumbered. 

operationally I think it would be a mess to have site-locals routed
differently within a site than globals.  it's not that you can't do it,
it's that it makes life more difficult, and GUPIs seem to be a better
way to solve the same problem.

Keith

---

From: Bob Hinden <[email-masked]>
Date: Fri, 13 Dec 2002 15:33:10 -0800

Keith,

>way to solve the same problem.

I am not sure there is that much difference.  In the current /48 provider 
based global addresses, each subnet is identified by a /64 prefix.  Both 
approaches will generate /64 routes.  I suspect that only in the largest 
sites, will the subnet field also be used for aggregation inside of the site.

This is all about tradeoffs.  For example in the site-local prefix 
FEC0::/10, there are 54-bits available for global identification and subnet 
numbering.  If 16-bits are for subnets, then there are 38-bits left for 
global site identification.  Is this big enough for a global 
token?  Probably not if it a random number or based on some other existing 
global identifier.  Might be OK if it was centrally allocated, but who is 
going to do that?  Also, what about sites that need more than 16-bits of 
subnets?

We could use a shorter prefix, but how much of the total IPv6 address space 
do we want to use for this?  For example, a /2 prefix would allow 16-bits 
of subnets and a 46-bit token.  But this would use 1/4 of the total IPv6 
address space.  That doesn't seem wise.

So I am not sure there is any solution that has the three properties:

  1) globally unique
  2) 16-bit subnet field
  3) Uses a limited amount of the IPv6 address space

We may have to pick the two we think are the most important.  The current 
site-local definition has 2) and 3).  My global site local proposal has 1) 
and 3).  Andrew White's draft has 1) and 3).

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Dec 2002 14:40:47 +0100

below...

> and 3).  Andrew White's draft has 1) and 3).

There is the alternative that can definitely be satisfied:

  1a) probably unique
  2) 16-bit subnet field

i.e. hash something into 38 bits that has a very high probability of being
unique among a finite number of sites.

   Brian