Subject: Globally unique link prefix alternative to site-locals

From: "Christian Huitema" <[email-masked]>
Date: Wed, 2 Apr 2003 12:14:51 -0800

The "anti-SL" arguments are primarily arguments aainst using ambiguous addresses. Ambiguous addresses are a royal pain in hosts that connect to multiple sites, either simultaneously or over time -- the applications need extra logic, and that creates bugs. But we clearly have an issue in the case of disconnected sites, intermittently connected sites, and ad hoc networks.
 
The "let's pick a prefix" argument is probably OK for large "managed" sites. In fact, most of the large sites have at least one IPv4 address and can pick a prefix; they could even obtain a provisional allocation from a friendly ISP. But this leaves out the small sites, the ad hoc networks, the unmanaged sites. However, if we just look at these small sites, we can easily get unambiguous *link* prefixes of the form:
                     <some-16-bit-prefix><unique 48 bit number>::/64
In a small site, these prefixes can be autoconfigured by routers, and then published in the IGP. If there are several routers on the same link, they can either elect a master prefix or just advertise one prefix each. Having unique per-link prefixes has quite a few advantages:
 
        - We get actual zero-configuration, a site can be just switched on.
        - Local connectivity can be used for adding a global addressing plan when the site joins the Internet.
        - Hosts can be multihomed at will; there is enough information in the address to find the right exit.
        - The addresses remain valid if a site is split, or if two sites are merged.
        - Unreachability is enforced by firewalls, not by bits in the address.
        - Since the link prefix is a /64, there is zero chance of having a nasty ISP leak it to the Internet.
        - If the /16 is well known, it can be plugged as "least preferred" in the address selection rules.
 
Is anyone interested in pursuing this design?
 
-- Christian Huitema

--------------------------------------------------------------------
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: "Tony Hain" <[email-masked]>
Date: Wed, 2 Apr 2003 12:38:23 -0800

This proposal is essentially what
draft-hinden-ipv6-global-site-local-00.txt does. I have no problem with
carving off a chunk of FEC0::/10 space for something like this, but that
approach does not solve all problems. In particular it creates an
unroutable mess for sites with a large number of subnets.

Tony

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]] 
Sent: Wednesday, April 02, 2003 12:15 PM
To: [email-masked]; Jeroen Massar; [email-masked]
Cc: [email-masked]
Subject: Globally unique link prefix alternative to site-locals

The "anti-SL" arguments are primarily arguments aainst using ambiguous
addresses. Ambiguous addresses are a royal pain in hosts that connect to
multiple sites, either simultaneously or over time -- the applications
need extra logic, and that creates bugs. But we clearly have an issue in
the case of disconnected sites, intermittently connected sites, and ad
hoc networks.

The "let's pick a prefix" argument is probably OK for large "managed"
sites. In fact, most of the large sites have at least one IPv4 address
and can pick a prefix; they could even obtain a provisional allocation
from a friendly ISP. But this leaves out the small sites, the ad hoc
networks, the unmanaged sites. However, if we just look at these small
sites, we can easily get unambiguous *link* prefixes of the form:
                     <some-16-bit-prefix><unique 48 bit number>::/64
In a small site, these prefixes can be autoconfigured by routers, and
then published in the IGP. If there are several routers on the same
link, they can either elect a master prefix or just advertise one prefix
each. Having unique per-link prefixes has quite a few advantages:

        - We get actual zero-configuration, a site can be just switched
on.
        - Local connectivity can be used for adding a global addressing
plan when the site joins the Internet.
        - Hosts can be multihomed at will; there is enough information
in the address to find the right exit.
        - The addresses remain valid if a site is split, or if two sites
are merged.
        - Unreachability is enforced by firewalls, not by bits in the
address.
        - Since the link prefix is a /64, there is zero chance of having
a nasty ISP leak it to the Internet.
        - If the /16 is well known, it can be plugged as "least
preferred" in the address selection rules.

-- Christian Huitema

---

From: Andrew White <[email-masked]>
Date: Thu, 03 Apr 2003 10:08:57 +1000

> Is anyone interested in pursuing this design?

Well, I have an implementation.

If Bob is happy, I'd like to grab most of his text (since it's better
written than mine) and wrap it around my bit-ordering proposal.

> the address selection rules.

I still have qualms with this.  I'm of the opinion that if site-locals exist
in a network then hosts should prefer them (iff both hosts have them); the
assumption is that SL addresses are at least as stable as externally sourced
addresses.

Of course, this policy will potentially be inappropriate for applications
that do address forwarding across a site boundary, but I'd argue that these
are the special case.  Apps that do address forwarding NOT across a site
boundary will be happy with the standard policy.

-- 
Andrew White

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 2 Apr 2003 20:18:07 -0600

----- Original Message -----
From: "Christian Huitema" <[email-masked]>
To: <[email-masked]>; "Jeroen Massar" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 02, 2003 2:14 PM
Subject: Globally unique link prefix alternative to site-locals

> The "anti-SL" arguments are primarily arguments aainst using ambiguous addresses. Ambiguous addresses are a royal pain in hosts
that connect to multiple sites, either simultaneously or over time -- the applications need extra logic, and that creates bugs. But
we clearly have an issue in the case of disconnected sites, intermittently connected sites, and ad hoc networks.
>
> The "let's pick a prefix" argument is probably OK for large "managed" sites. In fact, most of the large sites have at least one
IPv4 address and can pick a prefix; they could even obtain a provisional allocation from a friendly ISP. But this leaves out the
small sites, the ad hoc networks, the unmanaged sites. However, if we just look at these small sites, we can easily get unambiguous
*link* prefixes of the form:
> In a small site, these prefixes can be autoconfigured by routers, and then published in the IGP. If there are several routers on
the same link, they can either elect a master prefix or just advertise one prefix each. Having unique per-link prefixes has quite a

Are you on the AM Internet or the FM InterNAT ?

128-bit DNS AAAA Record Flag Day Formats
2003:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
[YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
1-bit to set the Reserved/Spare ("AM/FM") bit in Fragment Offset [S]
1-bit to set the Don't Fragment (DF) bit [D]
2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL]
1-bit for Options Control [O]
7-bits to set the Identification Field(dst) [FFFFFFF]
4-bits to set the TOS(dst) Field [TTTT]
Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000
FFF.FFFF.TTTT = GGG.SSSS.SSSS
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
IPv8
0QQQQGGGSSSSSSSS[32-bits][Port]
IPv16
0QQQQGGGSSSSSSSS[32-bits][Port]
1AAAAAAAAAAAAAAA[32-bits][Port]
A...A=ASN=32769...65535

Jim Fleming
http://www.IPv8.info

---

From: Shannon -jj Behrens <[email-masked]>
Date: Thu, 3 Apr 2003 07:24:35 -0800

> assumption is that SL addresses are at least as stable as externally sourced

Just a side note--my main point is below, but why is this the case?  If a 
router is still advertising a global prefix even though there is no global
connectivity, two local hosts can still communicate using that global 
prefix, correct?

> boundary will be happy with the standard policy.

I'm sure it's obvious, but apps that do address forwarding across site 
boundaries should probably just be aware that they are P2P apps and thus use 
a socket option that makes them prefer global addresses.  If this were a part
of the API documentation, I think this would be fine.

Best Regards,
-jj

-- 
Hacker is to software engineer as 
Climbing Mt. Everest is to building a Denny's there.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------