Subject: RE: Limiting the Use of Site-Local

From: Tim Hartrick <[email-masked]>
Date: Tue, 29 Oct 2002 16:40:38 -0800 (PST)

All,

I generally agree with all the points that Richard Draves has made.  I am
not as sanguine about the ease of implementation in the network stack
but there is nothing in the details which is unimaginably difficult.
We very much need to move on.  By my count this is the forth or fifth
time this topic has been debated and redebated.  Each time the result has
been the same.  If every decision taken by this working group can be
opened repeatedly by a noisy minority then forward progress of any
sort will not be possible.  Consensus does not require unanimity.  No
matter how noisy and persistent the minority happens to be, it is possible
to move on.

There are a couple of other points I would like to make.

Some folks seem to be operating under a misconception about RFC 1918.
RFC 1918 was a response to the rampant use of arbitrary IPv4 prefixes as
private address space.  The use of private address space was not a response
to the publishing of RFC 1918.  Network administrators will use "private"
IPv6 address space whether we excise all mention of site-local addresses
from the specifications or not.  The network administrators that use private
address space may be stupid, misinformed or have any number of socially
unacceptable habits but they still run their networks and will run their
networks the way they see fit. Removing site-local addresses from the
architecture or attempting to restrict their use in a way that is equivalent
to removing them is an exercise in futility absent better alternatives
to site-local addresses.

The burden on those that want to remove site-local addresses is to provide
network administrators with an alternative which meets their needs but
doesn't possess the negative aspects of site-local addresses that are
being railed against.  The requirements that network adminstrators
would place on these addresses would probably be that there is no registration
required and that the addresses are not globally routable.  If such a
proposal has been made and it has made it through last call of this working
group, I must have missed it.  Contrary to what has been said by some
in the anti-site-local camp, the burden should be on them to come up with
alternatives to site-local addresses.  Until those alternatives have been
thoroughly vetted by this working group the previous consensus should hold.

Counter to what one might believe from reading my comments above, I don't
like the architectural mess that has occured as a consequence of the use
private addresses in IPv4.  The difference between me and the anti-site-
local camp is that I don't anticipate that network administrators will
stop using private address (IPv6 or IPv4) unless they are provided with
good reasons not to use them.  That means solving renumbering, solving
address shortage, artificial or otherwise, providing the an alternative
"private" address scheme of the sort cited above and providing the great
IPv6 applications which their customers want but that break in the presence
of site-local addresses.  If these things are done, it won't be necessary
to add a bunch of MUST NOTs into the verbiage in various specifications.
Site-local addresses and all the associated problems will fall into the
dustbin of obsolescence.  Absent these things, all the MUST NOTs in the
world won't prevent the use of site-local addresses or some other form of
IPv6 "private" address.

Network administrators don't read RFCs for the MUST NOTs.  They read them
for the solutions they provide.  If the MUST NOTs get in the way of the
solution then they get ignored.

Tim Hartrick
Mentat Inc.

--------------------------------------------------------------------
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: Tue, 29 Oct 2002 21:07:16 -0500

> but there is nothing in the details which is unimaginably difficult.

The network stack isn't the problem; the difficulty of handling SLs 
in applications, coupled with their lack of benefit, is the problem.  

> been the same.  

No the result is not the same, because each time the debate crops up
again there is less and less justification for SLs.  The arguments
for SL were always weak, by now when the burdens associated with SL
are more apparent they're nearly indefensible.

> If every decision taken by this working group can be

Clearly we don't have a consensus that SLs are technically sound or that 
there is a compelling use case for them.  That should argue for our not 
burdening the network with them.

> to the publishing of RFC 1918.  

You are right about the first part, someone mistaken about the second.  
RFC 1918 was indeed a response to the use of arbitrary IPv4 prefixes;
and surely it was better to use a standard set of prefixes than arbitrary
ones.  But RFC 1918 has also repeatedly been cited to give license to
hooking private networks to the public Internet via NAT despite careful 
wording in RFC 1918 to NOT license such use.  

> Removing site-local addresses from the

Network admins can indeed screw with their networks and harm interoperability
of the global network by doing so, and there's nothing that we can do to 
prevent them from doing that.  But it's not IETF's purpose to tell network 
admins that it's okay to harm the network.  Rather, it's IETF's purpose to 
tell them how the network was designed to be used and which practices for
using the network make good sense.   SLs do not make good sense.

> being railed against.  

No, the burden on those who want to promote site-local is to figure out
how to have SLs exist without limiting the ability of the network to support
multiparty apps and without imposing a considerable burden on such apps.

We need justification to keep complex and burdensome features, not to 
justify getting rid of them (or replacing them with simpler features). 

> The requirements that network adminstrators
> required 

I think you're stating it a bit strongly.  I would say that there needs
to be a low barrier to obtaining addresses and that the process be
easily and widely understood.  But this doesn't by itself preclude some kind of
registration.  Sites don't seem to have major problems registering domain 
names, for instance.

> and that the addresses are not globally routable.  If such a
> group, I must have missed it.  

I've seen multiple proposals along these lines.
I certainly agree that these are needed - as I've said on multiple 
occasions, they are needed to facilitate private interconnection between 
private networks. 

> Contrary to what has been said by some

It seems to me that there's nowhere approaching a consensus to keep SLs
except for isolated networks.
 
> "private" address scheme of the sort cited above 

I agree with the above.   We *really* need to work on a complete
story for renumbering.  We *really* need a way for sites to get 
non-publically-routable (but routable between private networks), 
provider-independent address space.

> and providing the great
> of site-local addresses.  

this part makes no sense.   applications that don't work under such 
conditions don't get deployed very far - and people never get to use them.

Keith

---

From: Mark Smith <[email-masked]>
Date: 30 Oct 2002 16:53:37 +1100

Hi Tim,

I can provide a one network administrator's view, because that is all I
am.

In my experience, the main reasons network admins adopted RFC 1918
addressing were (in my naive days, I was one of them, thankforly(sp?)
not for long) :

1) the "security" benefits of non-routable address space.

2) the perception that public Internet address space was hard to get, if
not impossible.

The main justification for site local addressing in IPv6 seems to be so
that long lived TCP connections can survive site address renumbering.

While this sounds like a worthy goal, I wonder how many organisations
(individuals, enterprises, carriers) really have this requirement, other
than those mobile users that are served by Mobile IPv6.

Combining RFC1918 addressing with NAT would meet the same goal in the
IPv4 world, irrespective of the previous two reasons I suggested for net
admins adopting RFC1918 addressing. RFC1918 addressing in combination
with NAT effectively gives an organisation provider independant
addressing. An organisation can change their ISP, with a fairly simple
change to their NAT rules, having no impact on their long lived internal
TCP connections, and avoiding them having to renumber their internal
hosts.

Yet I've never heard of anybody implementing RFC1918/NAT for provider
independent addressing reasons. I'm sure there are probably instances,
but I think they are probably pretty rare.

It seems to me that the site local addressing feature suffers from a 
problem of the perceived benefits being far higher than the actual
benefits. The people on the anti-site local side fear the complexity,
the issues of passing scope, strangely failed connections due to passing
the wrong type (global/site) of address.

As a network admin, I ask questions such as "what is the geographical 
definition or size of a site when using site-local addressing".

Here in Australia it is quite common to have a data center in Sydney or
Melbourne, with the other major capital cities accessing it via a large
WAN (eg links typically 500 Miles or so long).

If I was to follow the true "site" definition of site-locals, I would
treat each office in each capital as a site, meaning that the interstate
TCP connections would be using global addresses - and therefore wouldn't
survive a renumbering involving global addressing.

However, with a /48 available for site local addressing, I'd be smarter
to treat the whole of Australia as a site, and avoid the global address
renumbering issues. So the name of "site-locals" is already wrong, but
things would be ok. "site-local" addressing should maybe be called
"continent-local" addressing perhaps.

Then I have to connect to an office in New Zealand (geographically
fairly close to Sydney), another continent. For the same, long-lived TCP
connection reasons, I'd probably include New Zealand as part of the same
instance of site-local addressing that I've created across Australia.
Hmm, not really continent-local addressing anymore.

If my company was now to merge with another company, who also had a
smart network admin (like me :-) ), who had also rolled out site-local
addressing across Australia, there is a reasonable chance that there is
overlap between our two separate instances of site-local addressing.

We could ring up our favorite vendor and say "do you sell IPv6 NAT
boxes, we need to translate between our two instances of site-local
addressing". This might be preferable to having to go and renumber
manually the site-local addressing that intersects across the two
instances. Alternatively we might be able to use the router renumbering
protocol.

However, if we don't use IPv6 NAT (presuming it exists), we have a
site-local renumbering event, which is going to impact some long lived
TCP connections - which is what site-locals addressing appears to be
trying to prevent.

In this example, I have already increased the geographic definition of
site-local addressing to better suit my needs, and yet still have not
managed to avoid renumbering issues. Using a pure "site-local"
definition of a site, my long lived TCP connection problems are worse.

So why bother with site locals at all ? At least with global addressing
I could merge the two companies without having to renumber the networks,
just push some backdoor routes around between them. Long lived TCP
connections within the domains of the previous organisations networks
will not be impacted.

If one of the ISPs wants to renumber, or we choose to change ISPs, well,
yes, the long lived TCP connections will go down, but that is a managed
and scheduled event. It can be planned in advance, people can take
appropriate measures to deal with it. I'd much rather deal with very
occasional, managed renumbering events, than all the unscheduled failure
events that can occur in a network, day in day out.

And that, as a network admin type person, is why I wonder what the value
of site-local addressing is.

Thanks for listening,
Mark.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 30 Oct 2002 15:09:56 +0200 (EET)

> provider-independent address space.

In the multi6 wg, there have been some proposals on the table on 
geographically assingned PI addresses.

If for nothing else, they could be useful in renumbering scenarios; having 
two sets of addresses, one which do not depend on your ISP, should make 
the renumbering a bit less painful.

-- 
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: "Tony Hain" <[email-masked]>
Date: Wed, 30 Oct 2002 13:00:43 -0800

Thank you!

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tim Hartrick
> Sent: Tuesday, October 29, 2002 4:41 PM
> To: [email-masked]; [email-masked]
> Subject: RE: Limiting the Use of Site-Local
> 
> 
> 
> 
> All,
> 
> I generally agree with all the points that Richard Draves has 
> made.  I am not as sanguine about the ease of implementation 
> in the network stack but there is nothing in the details 
> which is unimaginably difficult. We very much need to move 
> on.  By my count this is the forth or fifth time this topic 
> has been debated and redebated.  Each time the result has 
> been the same.  If every decision taken by this working group 
> can be opened repeatedly by a noisy minority then forward 
> progress of any sort will not be possible.  Consensus does 
> not require unanimity.  No matter how noisy and persistent 
> the minority happens to be, it is possible to move on.
> 
> Some folks seem to be operating under a misconception about 
> RFC 1918. RFC 1918 was a response to the rampant use of 
> arbitrary IPv4 prefixes as private address space.  The use of 
> private address space was not a response to the publishing of 
> RFC 1918.  Network administrators will use "private" IPv6 
> address space whether we excise all mention of site-local 
> addresses from the specifications or not.  The network 
> administrators that use private address space may be stupid, 
> misinformed or have any number of socially unacceptable 
> habits but they still run their networks and will run their 
> networks the way they see fit. Removing site-local addresses 
> from the architecture or attempting to restrict their use in 
> a way that is equivalent to removing them is an exercise in 
> futility absent better alternatives to site-local addresses.
> 
> The burden on those that want to remove site-local addresses 
> is to provide network administrators with an alternative 
> which meets their needs but doesn't possess the negative 
> aspects of site-local addresses that are being railed 
> against.  The requirements that network adminstrators would 
> place on these addresses would probably be that there is no 
> registration required and that the addresses are not globally 
> routable.  If such a proposal has been made and it has made 
> it through last call of this working group, I must have 
> missed it.  Contrary to what has been said by some in the 
> anti-site-local camp, the burden should be on them to come up 
> with alternatives to site-local addresses.  Until those 
> alternatives have been thoroughly vetted by this working 
> group the previous consensus should hold.
> 
> Counter to what one might believe from reading my comments 
> above, I don't like the architectural mess that has occured 
> as a consequence of the use private addresses in IPv4.  The 
> difference between me and the anti-site- local camp is that I 
> don't anticipate that network administrators will stop using 
> private address (IPv6 or IPv4) unless they are provided with 
> good reasons not to use them.  That means solving 
> renumbering, solving address shortage, artificial or 
> otherwise, providing the an alternative "private" address 
> scheme of the sort cited above and providing the great IPv6 
> applications which their customers want but that break in the 
> presence of site-local addresses.  If these things are done, 
> it won't be necessary to add a bunch of MUST NOTs into the 
> verbiage in various specifications. Site-local addresses and 
> all the associated problems will fall into the dustbin of 
> obsolescence.  Absent these things, all the MUST NOTs in the 
> world won't prevent the use of site-local addresses or some 
> other form of IPv6 "private" address.
> 
> Network administrators don't read RFCs for the MUST NOTs.  
> They read them for the solutions they provide.  If the MUST 
> NOTs get in the way of the solution then they get ignored.
> 
> 
> Tim Hartrick
> Mentat Inc.
>