Subject: RE: Appeal to the IAB on the site-local issue

From: [email-masked]
Date: Fri, 10 Oct 2003 11:09:22 -0400

Hi Scott,

Speaking only for myself, I would like to address a couple of the 
points that you have made.
 
> It is my opinion that there is a difference between a working group
> deciding to adopt a technology and a working group deciding 
> to delete a technology from an existing IETF specification.  It is my 
> opinion that the second case should require a stronger demonstration 
> of consensus to change since the decision effects existing implementations, 
> documentation, text books etc.

First, I disagree with your basic premise.  We don't make any 
distinction between these cases, but if we did, all other things
being equal, I think it should be harder to add a new feature to a 
specification than to take one out.  Removing a feature from a 
specification doesn't even prevent people from using it, whereas
adding a feature requires people to implement new code to be compliant
with the specification.

But, regardless of our differing opinions on this theoretical point, I 
am not sure how it applies to this situation.  Although a prefix for 
site-local addressing was set aside in the IPv6 Address Architecture 
(a PS RFC), the entire specification for the concept of site-local 
addressing, including how you would actually use these addresses, was 
only ever documented in the IPv6 Scoped Addressing Architecture I-D.  At 
the time that this decision was made by the WG, the latest version of 
that I-D had expired.  Various versions of the I-D had been considered
by the WG for years, but we had never reached rough consensus to send 
this I-D to the IESG for publication.

> The claim was made on the list that there was not consensus 
> to keep site local addresses, I think that is the wrong question 
> to ask -  the proposal was to change a specification after its 
> publication there should have been a rough consensus to remove the 
> feature.

I'm not sure where this is coming from.  You quoted the consensus 
finding later in your message:

> > The chairs have read all of the messages on the list, and 
> > based on your considerable input, we have determined that 
> > the IPv6 WG does have rough consensus to deprecate the usage 
> > of IPv6 site-local unicast addressing AND to investigate 
> > alternative mechanisms for local addressing and local access
> > control.

In other words, we found that there was consensus to deprecate AND
replace site-locals, not that there was a lack of consensus to keep
them.

In response to your appended letter:

> humm - it is not all that often that we have said that 2/3 is rough
> consensus in the IETF - in my exterience if 1/3 is not in support
> then I would not claim consensus (even 6 grit) - 3/4 would be very
> rough indeed, 5/6 would be the mininum I would say was "rough 
> consensus"

The actual ratio of YES to NO responses to this poll was closer
to 3/4.

Also, the poll was not the only tool that the WG chairs (I was
one of them at the time) used to determine the consensus of the 
WG.  There was considerable discussion regarding this issue -- in
the WG meeting and on the list.  This included a fairly large number
of people who gave conditional replies on the list, or who clarified
their meeting postion on the list along the lines of:  (1) I do not
think we should deprecate site-local unless/until we replace them,
or (2) Although I think that we should deprecate site-locals, I also
think that we need a replacement.  The chairs consensus call was
based on lengthy and careful consideration of all of the information
contributed by the WG, not just on the results of the opinion poll.

It is still my personal opinion that we correctly judged the 
consensus of the WG regarding this matter.

Margaret 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 10 Oct 2003 10:59:45 -0700

Additional input for your consideration.

[email-masked] wrote:
> ...
> replace site-locals, ...
Witness the situation where the chair is after the fact defining what the
working group agreed to. There was nothing about 'replacement' in the
question that was asked.

Coupling this with her earlier comment:
> I think it should be harder to add a new feature to a specification
> than to take one out.
shows that, now as AD, the bar for a disambiguated local range will be
higher if the pronouncement is allowed to stand, than what is necessary to
fix the existing specification.

Tony

---

From: Fred Baker <[email-masked]>
Date: Fri, 10 Oct 2003 11:34:04 -0700

At 08:09 AM 10/10/2003, [email-masked] wrote:
>Removing a feature from a specification doesn't even prevent people from 
>using it

I'm changing the thread subject. While this is relevant to the subject of 
Tony's appeal, it is also a general debate orthogonal to Tony's appeal. It 
is a side note that may prove relevant. While your assertion may generally 
be true, this particular change does prevent people from using it, and I'm 
not sure the assertion is true as worded.

The site-local proposal says that there is an assurance that a particular 
block of addresses is available to a network administration to use in 
whatever way it chooses within the confines of its own network, on the 
proviso that it neither advertise those addresses outside its network in 
routing nor trust announcements of the block by others, and presumably also 
ingress filters for the address prefix. Removing the concept removes that 
capability. YMMV as to whether you want the capability, but you cannot 
accurately say that the capability still exists once it has been removed.

Your assertion is also dangerous in protocols. If a capability is 
deprecated (remains defined but its implementation/use is discouraged, as 
for example true of TOS routing in OSPF, cf RFCs 1583, 2178, and 2328), 
then an implementation that contains the capability can accurately say it 
is using a superset of the specification. If the capability is simply 
removed, one has to presume that at some time in the future the bits will 
be reused with different semantics, making the implementation that 
yesterday was using a superset of the specification an active hazard today, 
and causing operational networks that were using the capability to have to 
make some potentially hard choices.

So in the general case I don't see a problem with deprecating things under 
the right circumstances, but I do have a problem with removing them 
outright. Deprecation doesn't prevent people from using them, but outright 
removal can be dangerous. And in this case, the assertion that one can 
still use the address prefix in a local manner is simply incorrect; it can 
be assigned at the whim of IANA, and network administrations need to plan 
accordingly.

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Oct 2003 15:40:11 -0400

> >Removing a feature from a specification doesn't even prevent people
> >from using it
> 
> I'm changing the thread subject. While this is relevant to the subject
> of Tony's appeal, it is also a general debate orthogonal to Tony's
> appeal. It is a side note that may prove relevant. While your
> assertion may generally be true, this particular change does prevent
> people from using it, and I'm not sure the assertion is true as
> worded.

Given that the objections to site local were based on the realization
that using it actually causes harm to applications and to the network,
then I agree with you.  Most of us realize that we cannot prevent
harmful behavior, especially on a private network.  But the intent of
deprecating site-local was at the very minimum to strongly discourage
its use.

> The site-local proposal says that there is an assurance that a
> particular block of addresses is available to a network administration
> to use in whatever way it chooses within the confines of its own
> network, on the proviso that it neither advertise those addresses
> outside its network in routing nor trust announcements of the block by
> others, and presumably also ingress filters for the address prefix.

It turns out that those usage constraints are not sufficient to avoid
harm to the network as a whole, and after numerous attempts we have 
not been able to define a set of constraints that still allow use of
site-local while avoiding that harm.

> deprecated (remains defined but its implementation/use is discouraged,
> as for example true of TOS routing in OSPF, cf RFCs 1583, 2178, and
> 2328), then an implementation that contains the capability can
> accurately say it is using a superset of the specification. 

The terms you are using are biased.  A vendor could define a "superset"
of IP that had the "capability" of routing addresses to destinations
other than those intended by the source, or modifying the contents of
messages sent by the source, or masquerading as the destination and 
issuing responses that appear to come from the destination.  A DNS
server could add the "capability" of misrepresenting the status of a
name given in a query.  Indeed, all of these "capabilities" exist in
some product or another.  It also turns out that all of these
"capabilities" cause harm to applications.

It's a fallacy to believe, and disingeneous to pretend, that 
providing new "capabilities" or a "superset" of a protocol is at worst
a benign activity.  There exist "capabilities" that do harm.  In the 
case of site-locals, it happens that this "capability" was part of an
IETF specification.  So once we realized that site-locals were harmful,
it became our responsibility to fix them.  I agree, as do most of us,
that we should make considerable effort to avoid disruptive changes to
published specifications.  However it was only after investigating
several proposals for less disruptive fixes, and finding all of them
insufficient, that there emerged a consensus to deprecate site-locals.

> If the
> capability is simply removed, one has to presume that at some time in
> the future the bits will be reused with different semantics, making
> the implementation that yesterday was using a superset of the
> specification an active hazard today, and causing operational networks
> that were using the capability to have to make some potentially hard
> choices.

We can promise to not re-assign them, and we can keep our promise.

But if site administrators decide to move away from site-locals, this is
a good thing, as it will minimize the harm done by having them in the wild.

Keith

---

From: [email-masked]
Date: Fri, 10 Oct 2003 15:55:06 -0400

> accurately say that the capability still exists once it has been removed.

On the flip side, the biggest basis for removing the feature is the fact that
RFC1918 contains essentially the same provision for IPv4, and 1918 addresses
are continually leaking like sieves, and nobody (to my knowledge) was able to
point at magic router filter dust that would prevent it from happening on IPv6.

So the basic concept is (in my opinion) broken and needs to be euthanized.

> be assigned at the whim of IANA, and network administrations need to plan 

And in fact, we've seen this effect in operation recently, when the 69/8 address
space was allocated but often unreachable due to bogon filters....

All in all, however, I think outright removal, although short-term more painful,
will be less troublesome than many years of debugging problems caused by
1918-style leakage of addresses for a "deprecated" feature.

---

From: Fred Baker <[email-masked]>
Date: Fri, 10 Oct 2003 14:29:24 -0700

At 12:55 PM 10/10/2003, [email-masked] wrote:
>All in all, however, I think outright removal, although short-term more 
>painful, will be less troublesome than many years of debugging problems 
>caused by 1918-style leakage of addresses for a "deprecated" feature.

That may be so. It is a third discussion, and is appropriate to the IPv6 list.

The first discussion is Tony's appeal, which is a procedural discussion and 
should not be debated on the basis of whether one agrees or disagrees with 
the particular feature (site-local addresses) but on the basis of whether 
the right consensus development and recognition procedures were followed. 
The Author/Editor of the procedural description has commented that it 
looked problematic to him.

The second is the side point I raised with Margaret: in the general case of 
"things in specifications", removing something from a specification does 
not mean that someone can still use it. Deprecation protects such a usage, 
but removal does not.

The third point, the one you address, is where all this started out, which 
is whether or not one should entertain site-local addresses at all. It is 
relevant to neither the procedural discussion nor the general discussion 
about removing features. But it is clearly something that the IPv6 working 
group needs to have a consensus opinion on. That is actually not the 
subject of either appeal, and should not enter into the discussion of 
either appeal, as it has no bearing on the thing appealed - which is the 
procedural issue. Using the wrong procedure to accomplish the right result 
(if one assumes that this is what happened) is just as bad as using the 
right procedure to produce the wrong result. One wants to use the right 
procedure *and* produce the right result.

When I changed the topic, I changed the subject line... Let's not confuse 
issues.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 10 Oct 2003 23:43:20 +0200

On vrijdag, okt 10, 2003, at 21:55 Europe/Amsterdam, 
[email-masked] wrote:

> the biggest basis for removing the feature is the fact that

> So the basic concept is (in my opinion) broken and needs to be 

This is based on the assumption that leaking RFC 1918 routing 
information or packets with RFC 1918 source or destination addresses is 
actually harmful in and of itself. This is a broken assumption. If 
people are going to send bogus routes or packets, then having RFC 1918 
addresses in them is the least harmful way to do it. Now obviously 
people shouldn't send out bogus routes or packets, but this is a 
problem that is completely unrelated to private addressing issues. It's 
just that private addresses make this problem much more visible. 
Removing that which is clearly wrong only helps to make sure the 
wrongness that remains is less visible.

And if you're unable to figure out how to filter private addresses in 
routing updates or IP traffic, there are numerous non-magical books out 
there that will tell you how to do this.

> 1918-style leakage of addresses for a "deprecated" feature.

Your argument is self-defeating. If we were to recycle FEC0::/10 this 
would be the 69.0.0.0/8 but ten times worse. Everybody knew that 
69.0.0.0/8 would be assigned at some point, so the people filtering 
this range knew what they were doing (or at least, they should have). 
FEC0::/10 on the other hand has been in the specification as a fixed 
special purpose range for a lot of years, and presumably people have 
implemented their networks accordingly. Pulling the rug from under them 
by removing this address range from the spefication and (at least 
theoretically) allowing it to be reassigned for a different purpose is 
insane.

And that's not even considering the lack of alternatives at this point 
in time. We may not be able to come up with a reasonable way for 
networks that implement site local addressing and interconnect with 
other networks that do the same, but there is still a very real need 
for addresses that can be used in disconnected IPv6 networks. I believe 
that forcing people who just want to interconnect a few boxes to do 
some testing to obtain globally routable IPv6 unicast space is a very 
bad idea. As long as there aren't any alternatives, FEC0::/10 should be 
used for this. And even after we have alternatives, FEC0::/10 should 
forever be set aside to avoid problems.

> <mime-attachment>

Huh?

Iljitsch van Beijnum

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Oct 2003 18:57:24 -0400

> actually harmful in and of itself.

no, it's based on (among other things) first-hand experience that applications
are expected to be able to use whatever addresses are given to them, regardless
of whether or not those applications employ hosts that are outside of site
boundaries.

> there that will tell you how to do this.

attempts to filter such traffic just makes the breakage worse.

---

From: [email-masked]
Date: Fri, 10 Oct 2003 19:12:55 -0400

> there that will tell you how to do this.

The problem is that usually, the offending site isn't the one feeling the pain.

We've been doing bogon filtering of 1918 addresses for a LONG time.

The *real* fun is collateral damage - we filter inbound 1918 source
addresses.  A certain clueless Tier-1 numbers their point-to-points
out of 1918 space.  If one of those links tosses an ICMP error,
it gets dropped at our border router.

Does wonders for PMTU discovery when the frag-needed packet gets tossed.

How many sites have to Get It Wrong before 30% of all the packets seen
at the root nameservers are from 1918 space?

> theoretically) allowing it to be reassigned for a different purpose is 

Agreed.  On the other hand, if we don't, we're stuck looking at
having inbound FEC0::/10 packets for eternity.

> forever be set aside to avoid problems.

Well.. OK... *disconnected* networks, I can see the point.  Unfortunately,
unless you make a rule that an IPv6 host will categorically refuse to
accept traffic to/from a FEC0::/10 host if it knows *ANY* other non-link-local
prefixes, it will end up leaking.  Yes, that means if you connect and learn
other prefixes, you need to renumber the site-locals.  It also means that
if you have a router talking to the outside world, you aren't allowed to do
NAT-style games - the router has to pretend your FEC0:/10 hosts don't exist.

> Huh?

RFC2440 - OpenPGP Message Format. J. Callas, L. Donnerhacke, H. Finney, R.
     Thayer. November 1998. (Format: TXT=141371 bytes) (Status: PROPOSED
     STANDARD)

---

From: Rob Austein <[email-masked]>
Date: Fri, 10 Oct 2003 20:06:17 -0400

No offense, folks, but if you really must have yet another round of
this interminable discussion, could you please trim the cc: list?
Four copies of each message is a bit much.  Thanks.

---

From: Leif Johansson <[email-masked]>
Date: Sat, 11 Oct 2003 08:46:04 +0200

Iljitsch van Beijnum wrote:
<snip>

|
| This is based on the assumption that leaking RFC 1918 routing
| information or packets with RFC 1918 source or destination addresses is
| actually harmful in and of itself. This is a broken assumption. If

Tell that to the root zone operators and brace for the reaction.

	Cheers Leif

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 11 Oct 2003 13:10:37 +0200

> Does wonders for PMTU discovery when the frag-needed packet gets 

Wouldn't the people behind this setup feel the pain too?

I must say giving a router that handles links with different MTU sizes 
RFC 1918 addresses is an interesting choice.

But then path MTU discovery has been broken (by assuming packet too big 
messages would *always* be returned) for 10 years and only recently the 
IETF and implementers have been starting to do something about that.

> at the root nameservers are from 1918 space?

Dunno. What kind of pathalogical setup makes this happen anyway? 
Running a resolving nameserver behind a broken NAT? But only a few of 
those will generate lots of queries as they never see any answers.

> having inbound FEC0::/10 packets for eternity.

I doubt that FEC0::/10 will be as prevalent as RFC 1918. But if you 
absolutely don't want to see them, you probably need to filter them for 
eternity, yes.

> NAT-style games - the router has to pretend your FEC0:/10 hosts don't 

Yes, all of this is very problematic. What we really need is provider 
independent address space that is globally usable. If we can't make 
this happen I'm sure IPv6 will end up with much of the IPv4 
unpleasantness, such as two-faced DNS if not full-out NAT.

>      Thayer. November 1998. (Format: TXT=141371 bytes) (Status: 

But why bother signing your messages? We're discussing based on 
arguments here, it doesn't matter who makes them...

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Mon, 13 Oct 2003 15:45:15 +0200

On Saturday 11 October 2003 08:46, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

Hello Leif,

Do you know what are the problems that *root zone operators* are 
experiencing with RFC 1918 addresses ? It would be very interesting
if you could explain (to me) some of these issues... I don't see why
this kind of addresses could be a problem, as long as they
don't use them....

-- 
JFRH

---

From: "Jeroen Massar" <[email-masked]>
Date: Mon, 13 Oct 2003 16:01:41 +0200

-----BEGIN PGP SIGNED MESSAGE-----

> this kind of addresses could be a problem, as long as they

You might want to read http://www.as112.net/

Quote: "Because most answers generated by the Internet's root name server system are negative, and many of those negative answers are in response to PTR queries for RFC1918 and other ambiguous addresses"

And that is only queries, you don't want to know how many RFC1918
sourced addresses they are dropping, can't send an icmp back now can you :)

Greets,
 Jeroen

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Tue, 14 Oct 2003 09:37:37 +0200

On Monday 13 October 2003 16:01, Jeroen Massar wrote:
> > > | information or packets with RFC 1918 source or
> >
> > destination addresses is
> >
> Quote: "Because most answers generated by the Internet's root name server
> system are negative, and many of those negative answers are in response to
> PTR queries for RFC1918 and other ambiguous addresses"
>

I would have to read it again, but I think that ICMP error messages are
sent with the source address of the output interface, so IMO it would be able
to come back. Anyway, thank you very much for the info Jeroen ^--^

-- 
JFRH

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 14 Oct 2003 11:36:49 +0200

-----BEGIN PGP SIGNED MESSAGE-----

<SNIP>

> > You might want to read http://www.as112.net/

<SNIP>

> I would have to read it again, but I think that ICMP error 
> messages are sent with the source address of the output interface, so IMO 
> it would be able to come back.

$stupiddevice --> non-filtering-ISP --> Transit --> Nameserver
 192.168.0.1                                         x.x.x.x

To which IP should the Nameserver, or for that matter anything
filtering in between send the traffic? In the DFZ there is no
route to 192.168.0.0/16, if there was is it is a still a bogon.
AS112 concentrates on bogus queries from valid IP's though as
the rootservers get queries for things like: 1.0.168.192.in-addr.arpa. PTR.

Mind you if the ISP doesn't even filter RFC1918 space they are not
filtering based on source address also. Thus that complete ISP is
a perfect source for..... spoofed ddos'ses, now track those ;)

ISP's should filter *any* source addresses that are not delegated
to their clients, doing this more at the edge where the client
connects to their network is a good thing. They should for
stupidity's sake also only forward traffic that they know the
destination is only at that client. Yes this breaks 'multihoming',
but is that real multihoming? Not per my definition at least.
uRPF etc come to mind also ofcourse.

Greets,
 Jeroen

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Tue, 14 Oct 2003 11:59:44 +0200

On Tuesday 14 October 2003 11:36, Jeroen Massar wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: Unfix PGP for Outlook Alpha 13 Int.
> Comment: Jeroen Massar / [email-masked] / http://unfix.org/~jeroen/
>
> iQA/AwUBP4vDpymqKFIzPnwjEQJ4+gCfav+ZRDKVvC75m21Y9ZUF+1YACbkAoJUI
> o7gclmYD8G7tWbqJ3n5mkm6O
> =gg+6
> -----END PGP SIGNATURE-----

> sourced addresses they are dropping, can't send an icmp back now can you :)

I was thinking that you were talking about packets with 
"src=global dest=private", and I just wanted to note that ICMP error
packets are sent with "src=<output_iface>, dest=global".

I see private addressing is a really bad idea, and I quite agree with
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-site-local-01.txt

See you and thanks again !

-- 
JFRH

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 14 Oct 2003 17:44:50 +0200

> this kind of addresses could be a problem, as long as they
Questions sourced from RFC1918 addresses and queries about RFC1918 
in-addr.arpa (which should be handled by the AS112 servers) are the top 
two garbage requests at i.root-servers.net.

- - kurtis -

---

From: Leif Johansson <[email-masked]>
Date: Wed, 15 Oct 2003 02:09:32 +0200

<snip>

|>Hello Leif,
|>
|>Do you know what are the problems that *root zone operators* are
|>experiencing with RFC 1918 addresses ? It would be very interesting
|>if you could explain (to me) some of these issues... I don't see why
|>this kind of addresses could be a problem, as long as they
|>don't use them....
|>
|
| Questions sourced from RFC1918 addresses and queries about RFC1918
| in-addr.arpa (which should be handled by the AS112 servers) are the top
| two garbage requests at i.root-servers.net.
|
| - kurtis -
|

Sorry I missed your question. Anyway: Yeah, What Kurtis said. I sent a
reference to a presentation to the list a few days back. It contains
numbers.

	leifj