Subject: Re: Textual Address Change for Scope-IDs

From: Erik Nordmark <[email-masked]>
Date: Wed, 1 Dec 1999 23:12:21 -0800 (PST)

> I would like to see us all agree that ONLY global addresses are in the
> DNS for sure.  That would be progress.

Jin and those who agree with the above statement,

I'm trying to find out how this relates to draft-ietf-ipngwg-site-prefixes.
Could someone please enlighten me what is broken in that draft.

Thanks,
    Erik

--------------------------------------------------------------------
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: Jim Bound <[email-masked]>
Date: Thu, 02 Dec 1999 10:06:59 -0500

Hi Erik,

>Could someone please enlighten me what is broken in that draft.

In your draft you put or assume site-locals are in the DNS.
I sent what section in mail to Itojun in our discussion.

Your draft should have its own mail thread.

/jim

---

From: Robert Elz <[email-masked]>
Date: Wed, 08 Dec 1999 23:34:10 +1100

Date:        Wed, 1 Dec 1999 23:12:21 -0800 (PST)
    From:        Erik Nordmark <[email-masked]>
    Message-ID:  <Roam.SIMC.2.0.6.944118741.7820.nordmark@jurassic>

  | I'm trying to find out how this relates to draft-ietf-ipngwg-site-prefixes.
  | Could someone please enlighten me what is broken in that draft.

The primary brokenness is the assumption that global prefixes and
sites are (more or less) one to one mapping (or many to one - global to site).

It is entirely reasonable to have one to many - one global prefix,
many different sites for site local purposes, the algorithm in the
draft then will allow nodes to use site local addresses that belong
to another site (and consequently which might reach some entirely
different node in the sender's site).

That could be fixed by defining a site to be all that can be reached
by any global prefix I guess, but that's broken too, as it is possible
to have two global prefixes and three sets of nodes, one set using one
prefix, another set using the other prefix, and the third set using both.
When you do that, unless you define that to be three different sites,
you get definition problems - if you define the whole thing to be one site,
then nodes in the first and second sets would fail the definition (remember
we are assuming here that a global prefix defines a site) - so they can't
be in the same site.   If you define it to be two sites, then nodes in the
third set all belong to two sites, which is (by the definitions of site
local addresses) impossible unless they have multiple interfaces, and
no-one is going to require that.  So, it must be three sites.   Now this
means that the algorithms in the draft would need (at least) to change,
instead of "If there are no matches" (sect 8.1) for site locals to not
be used, it will have to be "Unless every prefix matches".

Of course, as soon as we do that, then lots of nodes which could have
communicated using site locals fail to be able to communicate that way
and have to use globals instead.  This is not good.

The global prefix -> site assumption simply has to go.   Once that is
gone, and there is no relationship at all between sites and the global
prefixes that they use, then the whole basis for the draft falls apart.

More than that, determining what is the prefix of some other node based
upon DNS information is not possible (unless we add new information to
the DNS).   There's a hidden assumption in the draft (well semi-explicit,
as it says that the 16 bit "subnet" field must be the same in site locals
and globals) that a /64 is the net mask, always.   That need not be
true - /64 is only important when autoconf is being used, a site choosing
to use DHCP to configure its nodes' addresses might easily be using /96
or /120 or something as its netmask for some of its nodes.   Assuming that
the netmask is the same at the sender and destination (in the same classful 
address) was a flaw in early IPv4 that took ages to erradicate, let's not
start having nodes pretend to know anything at all about any other
node's address, other than its 128 bit pattern.

There's also the purity problem - the DNS is a global database, available
to all, and should only be returning data that is useful to all.  I get
to pay for all the bytes I receive (someone actually counts them), I really
don't want to have DNS packet sizes increased because they're carrying
site local addresses that are only useful on the other side of the world.
Let's keep global data in the global DNS, and do lookups of site addresses
in some local directory (of course, if you have no global addresses - that
is, you're not connected to the internet at all, then you can use a DNS
that is jus yours and is populated with your site local addresses, that isn't
an interesting case).

All that is needed is to decide just what kind of local directory should
be used for this, and how the lookups should be done, and by whom (ie:
where in the stack this all happens).

kre

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 1999 21:24:17 +0100

In your previous mail you wrote:

=> I believe Erik's idea is to put only globals in the DNS and to
use the knowledge of local site prefixes (given by prefix info
extensions in router advertisements) in order to replace globals
by site-locals in name to address translations when possible.
 This should work but if Erik promotes site-locals as a way to
keep local (ie. inside the site) connectivity during renumbering
personally I don't like site-locals for other purposes than net 10
(ie. never get both site-locals and globals) and I think a multi-sited
node will be a terrible monster...

Regards

[email-masked]

PS: two precisions:
 - I believe we can restrict the scope of this thread to textual addresses
   (ie. no DNS or other name to address translation)
 - even if we nuke site-locals we have still a problem with other scoped
   addresses like link-local and multicasts (but in these cases scope IDs
   can be interface indexes which are defined beasts :-).
--------------------------------------------------------------------
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: Erik Nordmark <[email-masked]>
Date: Wed, 8 Dec 1999 16:47:52 -0800 (PST)

> sites are (more or less) one to one mapping (or many to one - global to

Perhaps the draft is unclear but there aren't any frivolous assumptions
as far as I know. Maybe it is just the examples that are too simplistic
assuming that there are some number of /48 global prefixes assigned to
the site?

A site must have some finite (and presumably small) number of global
prefixes. Is this number is too large there will be routing scaling issues.
Thus if an entity (e.g. a company) has been assigned A/48 prefix
they might want to split that across different sites.
If all those sites are connected to the same ISP that might get away with that
- the ISP will need to carry longer than /48 prefixes for A.
But I don't think it is realistic that these longer prefixes visible
outside their ISP.
But even with their ISP the number will be small. I expect the ISP to
be unhappy (i.e. wanting more money) if they have to carry all the 65536
/64 prefixes for A (i.e. all the subnet routes). Thus there has to be
some hirarchy so that the prefixes are shorter than /64's.

In such a scenario all it takes it additional longer site-prefixes
being advertised in the router advertisement. Of course,
if you need to advertise lots of /64 prefixes as site-prefixes we will
have both a traffic problem due to the size of the logically fragmented
Router Advertisements, and also a storage problem on the hosts.

> different node in the sender's site).

No, you just need to correctly configure things. If a site
border router is injecting routes for A::1/56 and A::17/51 it can
use router renumbering (once that protocol passes the site prefixes)
to configure A::1/56 and A::17/51 as site-prefixes in the router
advertisements. Thus this can be automated.

What am I missing?

> and globals) that a /64 is the net mask, always. 

Where do you see the /64 assumption?
The only assumption is 
   The protocol assumes that the site uses a consistent subnet numbering
   scheme across all its global addresses and its site-local addresses.

This means that if a subnet uses e.g. a /120 (with the part between /97 and
/120 being the 23 bit subnet number) that the site-local and global addresses
for that subnet must both have a /120 with a 23 bit subnet number that is
the same in the two spaces.

> to all, and should only be returning data that is useful to all.

We have a few choices:
1. Don't do site-local addresses (or only have them apply to unconnected
sites). 2. Make sure they don't appear in the global DNS. As far as I can tell
this
   means they'll be in a local DNS i.e. we will need two-faced DNS in
   places where it isn't used today.
3. Put them in the global DNS but make sure that they are never used outside
   of their intended scope.

> that is jus yours and is populated with your site local addresses, that isn't

Won't this effectively mandate the use of two-faced DNS.
I thought we wanted to try to keep (or at least not move further away)
from a global DNS name space. Saying that the architecture mandates
a two-faced DNS seems impure as well.
Thus we can argue about which is more impure - shades of grey.

And it is my impression that a two-faced DNS is non-trivial to setup and
operate.

As an aside, we seem to have enough extensibility in the DNS to put
information in there that is not globally significant.
How about SIG records with algorithm = 254 that some random site
is allowed to use. When you ask for the SIG RRset you'll have to pay for
receiving those (presumably useless to you) SIG records. But as with
site-local addresses in this draft, you can tell what they are and not
get confused by them.

> where in the stack this all happens).

If we go that path, do you seriously think that the local directory will 
be anything other than DNS? I'm having a hard time understanding why
anybody would build a completely new local directory just for this.
And it would be slower since applications/OSs would need to look
in both the local directory and the DNS since they can't know where
the addresses will be stored. 

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 8 Dec 1999 17:47:32 -0800 (PST)

> by site-locals in name to address translations when possible.

Sounds like you should read the draft.

-00 of the draft did the above. What that has the downside that every node
in your site-prefix(es) need to be configured with site-local addresses.
The new (well, about 2 years old?) scheme provides flexibility by
controlling what goes in the DNS. For instance, a node that is likely
to be mobile might choose not to have site-local addresses in the DNS.

   Erik

---

From: "Matt Crawford" <[email-masked]>
Date: Thu, 09 Dec 1999 09:02:12 -0600

> prefixes. Is this number is too large there will be routing scaling issues.

No, I don't think so, as long as the global prefixes correspond to
the topology of their global connections.  If topological aggregation
is respected but the number of prefixes is truly pathological (order
of 100) I think the site is more likely to run into limits in the DNS
lookups for its own nodes.  A6 helps there, but only by a factor ~ 2.

> they might want to split that across different sites.  If all those
> sites are connected to the same ISP that might get away with that -
> the ISP will need to carry longer than /48 prefixes for A.

Or they could hide the structure even from the ISP by tunneling
between the different locations.  This is one of the cool things
about the elevated status of tunnels in v6 that is going to take a
while for the customer-at-large to grasp the possibilities of.

				Matt

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 9 Dec 1999 17:12:10 -0800 (PST)

> lookups for its own nodes.  A6 helps there, but only by a factor ~ 2.

I assume your are arguing about the (undefined) "small" above.
I can see there being on the order of 10 global prefixes for a site.
That means 10*24=240 bytes worth of prefix options in router advertisements
to carry the site-prefixes to the hosts.
I agree that 100 global prefixes would make life difficult but that difficulty
appears not only in the site-prefixes mechanism.

BTW: If a site has 100 global prefixes I don't think each host will have
100 addresses. A possible way such a thing could happen is that a site
starts of with a single Internet connection and a /48. They assign /64
subnet prefixes out of this space. Later they decide to outsource
the connectivity between their buildings to their ISP. In some weird case
they might actually want their ISP to carry the /64 routes, which are randomly
spread between the buildings. Thus each building could now be viewed
as a site with a set of /64 site prefixes.
But for various reasons (firewalls being one of them) I find such a scenario
unlikely.

> while for the customer-at-large to grasp the possibilities of.

Sure.

I can't see a case where a site would have more than one prefix (or a few once
they consume a full /48) per ISP they connect to.
Does anybody else have a case where this would make sense?
I'd like to understand if requiring scalability to 100's of prefixes per
site is reasonable.

   Erik

---

From: Robert Elz <[email-masked]>
Date: Fri, 10 Dec 1999 12:55:58 +1100

Date:        Wed, 8 Dec 1999 16:47:52 -0800 (PST)
    From:        Erik Nordmark <[email-masked]>
    Message-ID:  <Roam.SIMC.2.0.6.944700472.26654.nordmark@jurassic>

  | > The primary brokenness is the assumption that global prefixes and
  | > sites are (more or less) one to one mapping (or many to one - global to
  | > site).
  | 
  | Perhaps the draft is unclear but there aren't any frivolous assumptions
  | as far as I know.

I don't think I said "frivolous".

As I understand the draft, you use equivalence of global prefix (I have
this one, you have the same one) to mean "we are in the same site".
That's the assumption that I don't think can be maintained.

  | A site must have some finite (and presumably small) number of global
  | prefixes.

Why?

If you replace "site" there with "node" (and for now ignoring "small"
and nodes that actually get no global prefixes for one reason or other)
then yes, but for "site", why?   I have always considered a site to
be an administrative object, not necessarily related to external topology
any way at all (though "internally connected" is reasonable).   On the other
hand, global prefixes relate to connectivity and routing (the way they are
intended to be used in IPv6, as distinct from the original IPv4 model).

I don't see any specific relationship between the two at all.

All the rest of the stuff in your message about advertising of prefixes, etc,
is not immediately relevant.

  | > It is entirely reasonable to have one to many - one global prefix,
  | > many different sites for site local purposes, the algorithm in the
  | > draft then will allow nodes to use site local addresses that belong
  | > to another site (and consequently which might reach some entirely
  | > different node in the sender's site).
  | 
  | No, you just need to correctly configure things. If a site
  | border router is injecting routes for A::1/56 and A::17/51 it can
  | use router renumbering (once that protocol passes the site prefixes)
  | to configure A::1/56 and A::17/51 as site-prefixes in the router
  | advertisements. Thus this can be automated.
  | 
  | What am I missing?

You're assuming that "correctly configure" means "configure so that site
locals will work the way that the draft assume".   That isn't my definition
of correctly configuring global addresses.   My definition of a correctly
configyured global address is one that makes the routing work the way I
expect it to work, and has no relationship at all with what I choose to
define as my site for site local addressing purposes.

That is, I see no relationship at all between what global prefixes
might exist, and how they are advertised on the various links, and
what is a "site".  My definition of a site is more along the lines of
"all those nodes and links configured to route packets for using
site local addresses" - where there's a block, site locals don't pass
from this link to that one, then there is a site boundary, where there
is no block, then the same site continues.   No more, and no less,
restrictions than that.

As I said in an earlier message on another topic (which sort of led to
this one) I don't think we yet really know enough about how we want to
make use of sites, and site local addresses, to start laying down the
rules for how they have to be used.

  | Where do you see the /64 assumption?

Not the precise number, but that there is a number.

  | The only assumption is 
  |    The protocol assumes that the site uses a consistent subnet numbering
  |    scheme across all its global addresses and its site-local addresses.

No, more than that.

  | This means that if a subnet uses e.g. a /120 (with the part between /97 and
  | /120 being the 23 bit subnet number) that the site-local and global addresses
  | for that subnet must both have a /120 with a 23 bit subnet number that is
  | the same in the two spaces.

Yes.  It also means, I believe, for the draft to work, that all the nodes
have to understand at least the /120 number.   If that node over there is
/64 and I am /120 am I going to recignise it as being in the same site as
I am?

  | We have a few choices:
  | 1. Don't do site-local addresses (or only have them apply to unconnected
  | sites).
  | 2. Make sure they don't appear in the global DNS. As far as I can tell
  | this
  |    means they'll be in a local DNS i.e. we will need two-faced DNS in
  |    places where it isn't used today.
  | 3. Put them in the global DNS but make sure that they are never used outside
  |    of their intended scope.

Those are options, I don't see them as the only options.   In my previous
message I deliberately didn't attempt to suggest a solution, as no
solution is likely to be perfect - they all have some drawback or other.
Suggesting a solution now would focus discussion on pulling apart that
suggestion, rather than on whether or not the current one will work.

  | Won't this effectively mandate the use of two-faced DNS.

No.

  | I thought we wanted to try to keep (or at least not move further away)
  | from a global DNS name space. Saying that the architecture mandates
  | a two-faced DNS seems impure as well.

Yes, That is not at all what I would like to see.

  | And it is my impression that a two-faced DNS is non-trivial to setup and
  | operate.

Yes, horrible.   But irrelevant, as that is not what we want (not what I
want anyway).

  | As an aside, we seem to have enough extensibility in the DNS to put
  | information in there that is not globally significant.
  | How about SIG records with algorithm = 254 that some random site
  | is allowed to use.

That is global information - available equally to everyone, and entirely
possibly meaningful to everyone.   The only issue there is whether the
node that receives the information just happens to know how to interpret
it - the DNS isn't deliberatey returning information that cannot possibly
be of any use to you.

Further, note that I am not saying that the DNS is unable to carry the
information that you are considering putting there - aside from the
extra data volume to lug around, of course it can.   The DNS can hold
almost anything.   That doesn't mean that it should.

  | If we go that path, do you seriously think that the local directory will 
  | be anything other than DNS?

Yes.

  | I'm having a hard time understanding why
  | anybody would build a completely new local directory just for this.

Perhaps because nothing else will work sensibly, and flexibly, enough.

  | And it would be slower since applications/OSs would need to look
  | in both the local directory and the DNS since they can't know where
  | the addresses will be stored. 

Even leaving aside the assumption that exists there about the nature of
this new directory (I didn't suggest that it would be anything like the
DNS at all = "directory" just means a place from which information is
obtained) "slower" would not be correct.  More overhead yes, but it is
hard to imagine a site local directory that would actually be slower
than the global DNS, and nothing at all would suggest that the two lookups
(again, assuming that there are two lookups this way) need to be
serialised.

But, for now, let's not just say "we must do this because we cannot
think of anything else right now that will work", and instead analyse the
proposal on its own merits.

kre

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 9 Dec 1999 18:50:51 -0800 (PST)

> I don't think I said "frivolous".

Correct. My bad.

> That's the assumption that I don't think can be maintained.

If you are talking about the addresses/prefixes assigned to me and you,
then the answer is no.

I check the global addresses I get from the DNS (for your name) against
the set of prefixes the routers have told me are part of my site.
(I may or may not have addresses in all those prefixes.)
Assume A:1/48 and B:2/48 are advertised as site prefixes.
When the DNS returns A:1:16:9 and fec0:16:9  
for your name I will (independent of my own addresses) prefer communicating 
with the site-local address.
If the DNS returns something that doesn't fall in A:1/48 or B:2/48
I will ignore any site-local address returned.

Since the site border router typically knows all prefixes assigned to
the site (it advertises them externally) it can use yet-to-be-specified
extensions to router renumbering to carry this information to all the routers,
which will use the specified mechanism to carry this to the hosts.
Thus no extra configuration.

> intended to be used in IPv6, as distinct from the original IPv4 model).

I think I'm starting to understand where you are comming from.
My assumption is "a site is a site". Thus the region where are site-local
address is unique and routable is the same region that is assigned some
length prefix (possibly multiple) from each of the ISPs it connects to.

You seem to be saying that this might not be the case - that the internal
view of the site (the scope over which a site-local applies) might be larger
than the external view of the site (the global prefixes assigned to the site).
Is this the case?

As an aside, one can avoid the introduction of "external view" and "internal 
view" of a "site" by instead stating that the site is where a site-local 
address is unique and routable, but that various parts of the site use
different global prefixes - presumably those that are associated with closeby
border routers. I'd prefer using that terminology to avoid introducing
different views of a "site".

The site-prefixes draft handles this case. The prefixes used in the region
I'm in will be advertised with the L (onlink), A (addrconf), and S (site
prefix) flags set and the Site Plength set. Thus for efficiency reasons the
site prefix information is piggybacked on the subnet prefixes in the same
option. The site-prefixes that have no corresponding subnet prefix in my region
will be advertised with just the S flag and Site Plength set.

The only issue is the total size of the advertisement.
If there will be 15 site prefixes and 3 subnet prefixes each router
advertisement would have 15*64=832 bytes of prefix options.
But if there are 100 site prefixes each logical router advertisement would be 
split over 6 packets each carrying a subset of the prefix options. This
seems obsessive.

In any case, the adminstrator has full freedom to designate both what
constitutes a site (the area where site-locals are unique and routable)
and what addresses are assigned in the various regions of the site.

> is no block, then the same site continues.   No more, and no less,

And the draft handles that as far as I can tell.

> /64 and I am /120 am I going to recignise it as being in the same site as

No. The nodes use the Site Plength sent in the prefix options.
Doesn't require any knowledge of bit boundaries. Doesn't assume
the same bit boundaries are used for all site prefixes.
Doesn't assume my addresses have the same bit boundaries as your addresses.

Hopefully this has clarified how the protocol works so I won't respond
to your other comments at this point in time.
And if I haven't clarified how the protocol works we need to get over that
hump first.

   Erik

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 10 Dec 1999 08:33:03 -0600

> I'd like to understand if requiring scalability to 100's of prefixes per

Leaving aside the question of whether it's a reasonable requirement,
I don't think intra-site routing and ND have a problem at that
level.  The first crunch I can see will be in DNS replies, and the
next one in source/destination address selection.

			Matt