Subject: RE: Limiting the Use of Site-Local

From: Margaret Wasserman <[email-masked]>
Date: Mon, 28 Oct 2002 11:49:31 -0500

>
>=> This makes a lot more sense IMHO. How can we write
>"MUST NOT use site-local when global addresses are available"
>in a spec? I mean how can we enforce that? If we can't enforce
>a "MUST" or "MUST NOT" then it shouldn't be in the spec
>in the first place.

I disagree.  The scoped addressing architecture will define how
scoped addresses are used on the network.  It already has lots
of things in it that can't be "enforced" programmatically on a
single node, such as:

         - scope boundaries are in nodes, not on links
         - scopes are contiguous and convex
         - smaller scopes are completely contained within
                 larger scopes

All of these things require that an administrator configure a
network in a way that meets these guidelines.

Similarly, we could say that site-local addresses should not be
assigned on globally-connected networks.

Besides, it would be possible (although perhaps not adviseable)
to enforce this restriction.  Nodes could immediately deprecate
site-local addresses whenever a global address is configured.

Margaret

--------------------------------------------------------------------
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: Margaret Wasserman <[email-masked]>
Date: Mon, 28 Oct 2002 12:04:02 -0500

>
>=> Just so they feel that they followed our standards?
>I don't think so. A much better approach IMHO would be
>to highlight the problems and discourage people from
>using site-local addresses for globally connected sites
>_because_ of the highlighted problems. After that you
>can hope that people will follow. That's all we can do.

And, in this scenario, do we also document all of the things that
are needed to make things sort-of work when administrators ignore
our advice -- "two-faced" DNS, a complex nest of address selection
rules, routing protocol rules for SBRs, etc?

And, do we require (in node requirements) that people implement
all of this cruft?

If so, how are implementors supposed to distinguish between the
things that they really need to implement (to make the usual
case work), and the stuff that they only need to implement to
support the not-recommended case?

Margaret

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Mon, 28 Oct 2002 18:19:39 +0100

> rules, routing protocol rules for SBRs, etc?

=> Well, if one says "Administrators MUST NOT do X"
there is no need to show them how to go around that MUST NOT ;)
But you could use the reasons you mention above to justify
the MUST NOT.

  > And, do we require (in node requirements) that people implement

=> Why would we do that if the recommendation is: "MUST NOT use
SL addresses for globally connected networks" ??

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Mon, 28 Oct 2002 18:12:09 +0100

> "Hesham Soliman (EAB)" wrote:
  > 
  > >       ....       A much better approach IMHO would be
  > > _because_ of the highlighted problems.
  > 
  > Doesn't this boil down to saying "SHOULD NOT" instead
  > of "MUST NOT"?

=> Possibly. But my comment was that we explain 
the reasons in detail. That's why Steve's suggestion
about a BCP made sense to me. 

Hesham

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 28 Oct 2002 12:32:57 -0500

Okay, good.  It looks like we are, somewhat, on the same page.

Let's try to figure out what restrictions we think would make
sense, then we can figure out whether it makes the most sense
to document them in a standards track document or a BCP, okay?

Margaret

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Mon, 28 Oct 2002 20:42:44 +0100

> > => It has a better chance of working this time because:
  > > - No one expects addresses to become a scarce resource in our
  > > lifetime anyway
  > > 
  > > - I haven't seen any plans by ISPs to charge based on 
  > > the number of addresses. 
  > > 
  > > So, I don't think it's quite the same problem as with
  > > RFC1918.
  > 
  > I agree that scarcity is not the issue.  Rather, the end user
  > sees it as simpler to slap a NAT in the network and connect
  > rather than go through and renumber the network.

=> I completely agree that this is a possible scenario, 
but I also think that:

1. We will not eliminate stupidity or ignorance from the 
Internet. 

2. The people that do that might have their reasons...I can't
think of any and I wouldn't advice it, but...some people do. 

3. Even if SLs were eliminated, what's going to stop 
someone from using _any_ bitstring for their internal
addresses and when they want to connect to the Internet
they will still throw a NATv6 on the edge. Why is this
better?

Deprecating site locals to aovid the scenario above 
is a futile attempt IMHO. 

Hesham

  > Brian

---

From: "sasson, shuki" <[email-masked]>
Date: Mon, 28 Oct 2002 16:13:20 -0500

Hi all, indeed scoping is a pain... specifically since it is not carried as
a part of the address.
In any case we should give an escape path out of this ambiguity to a "known"
world. 
Meaning if a node is configured with a global addresses the global addresses
will have higher priority being used as a source address over SL.
Since the IPv6 transformation is expected to be evolution(vs. revolution) I
believe the vast majority of the networks will choose to take this path.
I know there is a draft in the work for this, and I believe this is what it
says (correct me if I am wrong...).
This way the vast majority of users knows there is a way to get over this
problem... 
This is also solves the scoping problems for LL and multihome hosts.  

Shuki
-----Original Message-----
From: Dan Lanciani [mailto:[email-masked]]
Sent: Monday, October 28, 2002 3:52 PM
To: [email-masked]
Subject: RE: Limiting the Use of Site-Local

I think it's great the folks are starting to consider the difficult problems
associated with site-local addresses in particular and scoped addresses in
general.  In the past these have been glossed over with hand-waving
arguments
that scopes would ``just work'' with minimal application involvement and a
little DNS magic.

Before you try to solve the problems by effectively reducing scopes to a
degenerate case of one and restricting site-local addresses to sites with
no global addresses (or even with no external connectivity), please keep in
mind that site-local addresses have been offered up as the solution to a
number of other problems which themselves were difficult to hand-wave away.
For example, the ability to have long-term tcp connections within a site in
the face of global address renumbering has--given the lack of any protocol
or application support for that renumbering--been pushed onto site-local
addressing.  (The problem is hardly confined to tcp, but that's the usual
example cited.)

Any language that reduces site-local addresses to second-class citizens (or,
worse, implies that they should not be used concurrent with global
addresses)
will give stack and application vendors an excuse to fail to support such
configurations.  I don't think you want to open such a huge can of worms as
it will entail revisiting every problem that has been ``resolved'' with an
admonition to simply use site-local addresses.

				Dan Lanciani
				ddl@danlan.*com

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 28 Oct 2002 23:24:24 -0500

We should not have to touch addr arch if we just want to control SLs and
not Revoke them.

Just to leave addr arch ALONE I vote for "control" now even though I
want revoke and think SLs are a curse to IPv6 in the future. Lets
control it.  We have to leave addr arch alone unless there is no other
alternative.  Margaret's paradigm presents us that alternative and I
think it will work.

There is no perfect world there will NEVER be a perfect protocol.  I
recall one Ipng directorate member when we sat there looking at all the
proposals.  One in particular kept saying which one has less "warts" (a
very bright guy named Greg :--)).  I have taken those comments to heart
in all IETF work as much as be liberal (I really just hate that word
:--)) in what you receive but conservative in what you send.  IMO SLs
are an IPv6 wart.  Lets not cut off the hand where the wart is but
rather kiss it and make it beautiful like in those children stories. The
problem is the wart is so ugly no one wants to get close and best we can
do is put bandaid on it for now.  That is what Margarets proposal does
and it appears to me there is consensus to move forward with that idea.
At least my read of these far to many emails but necessary I guess.

/jim

/jim
[Have you ever seen the rain coming down on a sunny day]

> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Monday, October 28, 2002 2:53 PM
> To: Margaret Wasserman
> Cc: Hesham Soliman (EAB); 'Keith Moore'; 
> [email-masked]'; 'Steven Blake'; [email-masked]
> On Mon, 28 Oct 2002, Margaret Wasserman wrote:
> > >2.5.6 Local-Use IPv6 Unicast Addresses
> > >
> > >    Routers must not forward any packets with site-local source or
> > >    destination addresses outside of the site.
> > >
> > >This conflicts with the "treat as globals" stance.
> > 
> > Not really.  If we define that site-local unicast addresses 
> can only 
> > be used on non-globally-connected sites, there won't be any site- 
> > border routers that need to worry about this restriction.
> > 
> > But, that doesn't make the restriction false.  Site-local addresses 
> > should never be forward outside of a site.
> 
> And what about:
> 
>    Site-local addresses are designed to be used for 
> addressing inside of
>    a site without the need for a global prefix.  Although a subnet ID
>    may be up to 54-bits long, it is expected that globally-connected
>    sites will use the same subnet IDs for site-local and global
>    prefixes.
> 
> 
> I think if we want to go down the road discussed in this 
> thread, I believe 
> some (relatively minor) changes in addrarch could clarify many things.
> 
> -- 
> 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: "Bound, Jim" <[email-masked]>
Date: Mon, 28 Oct 2002 23:47:27 -0500

Dan,

This is quite a good commentary.  What you say is exactly what will
happen too in the commercial deployment of IPv6 (as opposed to AD,
research, and non fully supported product where the vendor states you
can use this in your production network).

But I have heard this TCP long lived connection discussion for a long
time.  Lets discuss.  But first anyone who believes they have the right
to keep telnet up 24 hours a day across global networks is sadly
mistaken and that's just crazy and lets evil security bad people really
get to test their skill out.

I know of a user who has to have long lived TCP connections in mission
critical situation and wants to do it with IPv6.  I have advised them to
NOT use SLs.  Here is why.  The user implementation will have user
internal routers across the site (properly defined).
But people in the site will and must have access out of the site and
that is why we have that problem long discussed here in reality from a
few users.  That is critical for IPv6 to solve right now.  Margaret's
proposal solves that problem and will save lives IMO with IPv6.

But TCP because we have sites and not multiple links connected using
global addresses I don't believe provides any more guarantee or
robustness for a long lived TCP connection on a site.  Simply because
the only reason it will break the site TCP is an error in the network
administration, router going down (then we get into dual rail but lets
not go there for now), or the cosmos sends a lighting bolt into the core
router of the site.  So SLs buy a site TCP long lived connections
nothing I can see over global addresses.  The only place that is not
true is a link.  And for that we do have link-local.  So I still do not
see the value of SLs even for long lived connections.

The way to solve long lived connections and this is even more hairy than
SLs and that is by dynamically reconfiguring the two nodes to use
different addresses and vendor customized True High Availability for TCP
and SCTP (I believe SCTP is better now just like IPv6 is better than
IPv4 but needs more testing and trial networks).

So I am not clear your argument of long lived connections is an argument
for SLs?  It is an argument for other work I believe to be important.

/jim

> I think it's great the folks are starting to consider the 
> difficult problems associated with site-local addresses in 
> particular and scoped addresses in general.  In the past 
> these have been glossed over with hand-waving arguments that 
> scopes would ``just work'' with minimal application 
> involvement and a little DNS magic.
> 
> Before you try to solve the problems by effectively reducing 
> scopes to a degenerate case of one and restricting site-local 
> addresses to sites with no global addresses (or even with no 
> external connectivity), please keep in mind that site-local 
> addresses have been offered up as the solution to a number of 
> other problems which themselves were difficult to hand-wave 
> away. For example, the ability to have long-term tcp 
> connections within a site in the face of global address 
> renumbering has--given the lack of any protocol or 
> application support for that renumbering--been pushed onto 
> site-local addressing.  (The problem is hardly confined to 
> tcp, but that's the usual example cited.)
> 
> Any language that reduces site-local addresses to 
> second-class citizens (or, worse, implies that they should 
> not be used concurrent with global addresses) will give stack 
> and application vendors an excuse to fail to support such 
> configurations.  I don't think you want to open such a huge 
> can of worms as it will entail revisiting every problem that 
> has been ``resolved'' with an admonition to simply use 
> site-local addresses.
> 
> 				Dan Lanciani
> 				ddl@danlan.*com

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 28 Oct 2002 23:51:30 -0500

Roy,

I agree with you but another point I really don't like.  In the
situation in same site per your statement below.  A node could send to a
dst addr with less scope in its src.  If the packet goes far enough it
can never return (kind of like charlie on the MTA in Boston).  Another
property of SL I don't like.  But before we gave imnplementational and
operational real thought to SLs and lumped them in IPv6 we had this same
problem.  With Link-Local.  What is the point of sending to a global
address with a Link-Local?  That's unidirectional.  Just another point
of darkness about SLs.

/jim

> From: Roy Brabson [mailto:[email-masked]] 
> Sent: Monday, October 28, 2002 3:58 PM
> To: [email-masked]
> Cc: [email-masked]
> > I have a basic problem with this thread. We have a few people 
> > discussing fundamental changes in close to a vacuum. At best the 
> > result of this discussion should be a separate BCP, but before that 
> > happens operators of networks that actually use 1918 space 
> need to be 
> > engaged to find out their requirements.
> > 
> > The whole idea that SL should be revoked if a global is 
> available is 
> > bogus. It is certainly reasonable for the manufacturer of light 
> > switches to only support SL/LL rather than potentially 
> multiple global 
> > prefixes. There is no reason for those devices to interact across a 
> > scope boundary, so the peer nodes that may also need global access 
> > MUST keep their SL to interact in the limited scope.
> 
> I thought global addresses could be used to communicate with 
> peers using 
> addresses of any scope as long as the interface over which 
> the packet is 
> sent is in the same scope zone as that peer.  As such, a node with a 
> global address does not require a site-local address to 
> communicate with a 
> node which has a site-local address but lacks a global 
> address, as long as 
> the two nodes reside within the same site.
> 
> Roy

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 29 Oct 2002 00:02:34 -0500

As one implementor.  They create so many conditionals in the code
because they are virtual to ship it means like major testing that does
not exist today for networking.  That is not a reason not to do
anything.  But if it is baked (I don't think it is yet) it is rather
cumbersome to build a product with it that won't break.  I mean a
product that has a total warranty on it and means to the user "you can
run this in a production operation and we will be responsible".
Not an early adopter kit OK.

/jim

> From: Margaret Wasserman [mailto:[email-masked]] 
> Sent: Monday, October 28, 2002 4:56 PM
> To: Dan Lanciani
> second-class citizens 
> >(or, worse, implies that they should not be used concurrent 
> with global 
> >addresses) will give stack and application vendors an excuse 
> to fail to 
> >support such configurations.
> 
> What do stack and application vendors need to do to support 
> site-local addressing?
> 
> And what makes you think that they are doing those things now?
> 
> The majority of stack and application implementations with 
> which I am familiar make no distinction at all between 
> site-local address and globals.
> 
> This is appropriate if site-locals will be used only on 
> non-globally connected sites (so, effectively, site-local == global).
> 
> Margaret
> 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 29 Oct 2002 00:12:55 -0500

Michel,

There is now debate if sensors should even have IP addresses and if IP
is even needed.  Clearly the Gateway sensors will need IP but then that
should not be SL but global in the sense of global for the gateways
communications.  And most sensors are dealing with speeds across the
plane of physics where IP stacks would be a bottleneck as we know them.

/jim

> From: Michel Py [mailto:[email-masked]] 
> Sent: Monday, October 28, 2002 5:04 PM
> To: Margaret Wasserman; [email-masked]
> > Margaret Wasserman wrote:
> > I've spent much of the last 7+ years working on IPv6
> > stacks for embedded systems, and they have all
> > supported global addressing.
> 
> The issue is not the capability of the devices to support 
> global addressing, but the desire of the network designer to 
> configure a set of devices that specifically don't have 
> access to the public address space.
> 
> There are some military applications where devices have no 
> business talking to the outside world. Control devices or 
> sensors on a water distribution system or a power grid are 
> another good example. These devices have no business 
> whatsoever accessing the public internet, and it might be a 
> requirement that the devices themselves have support for 
> public addresses removed.
> 
> Michel.
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 29 Oct 2002 00:18:45 -0500

Michel,

There is not reason at all why what you stated could not be link-local
addresses.  I would argue if sensors do what I hear they will do
link-locals are fine and we do have controls on that and they are not
forwarded off the link.  The cockpit and intra-connections could be
viewed as on link easily.  Access to the FAA or GPA Sat-Com would
require global (hmm maybe inter-planetary scope :--)) and as in my
previous mail those would be gateways to the sensors.

You may give good argument to not kill them yet but not sure against
what Margaret proposed.

/jim

> Sent: Monday, October 28, 2002 5:46 PM
> Margaret,
> > What would a light switch do differently to support site-local as 
> > opposed to global?  It still needs to get a prefix from a 
> router and 
> > combine it with an IID using address autoconf.  So, I don't 
> understand 
> > what system requirements could be eliminated by refusing
> > to support global prefixes.
> 
> There is a matter of _implementing_ system requirements, not 
> eliminating them.
> 
> Let's talk about an airplane's IPv6 internal systems. There 
> will be a requirement that the rudder's embedded controller 
> reacts to site-local only, just in case a bozo mixes up 
> something. OTOH, the NAV computer does need to talk to the 
> outside word to extract weather or other in-flight dynamic 
> data and to report to ground.
> 
> All that stuff is displayed simultaneously on the glass 
> cockpit CRTs, so at some point there is one computer in the 
> plane that has access simultaneously to external data and to 
> internal data.
> 
> Now, explain me how you design that network (the plane) with 
> deprecating site-locals when global addresses are present. 
> Modern plane designs are multiple redundant networks that 
> carry data for almost all of the plane's devices.
> 
> Michel.
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 29 Oct 2002 00:26:05 -0500

Michel,

All know now that NAT breaks security and destroys end-2-end.  In the
other part of my life and it sounds like we talk to similar people, I am
struggling now with the other transtion and that is from NAT.  But its
not like people like it :---).  Its kind of like your kid is on drugs.
You still love the kid but it would be nice if you could get them off
drugs.  NAT hides stuff clearly and stuff that also does bad things to
the network as a note and one of its uses I find lately, but its not a
plan to move forward.  And we will need to provide that security with
IPv6 as a note that they did not get with NAT.  So this entire private
address/NAT illusion put down on folks now will affect us still but we
can fix it now with strong security for IPv6 and doing what Margaret
suggested and Tony has suggested and we can leave it in the architecture
for now till a later day.

I think we are all in violent agreement here? 

Leave the architecture alone for tomorrow.

Use Margarets fix as BCP or whatever.

Michel and I can use it in physics experiments tomorrow.

And we can work on the next important topic for v6ops?

And what Dan wanted too I think that is another task but probably not
here.

/jim

> To: Alain Durand
> > Alain Durand wrote:
> > Oh... the old argument that NAT/private address
> > brings security...
> 
> Go tell that to people that write requirements, especially 
> the ones that work for the government, and when you have 
> convinced them get back to us, ok?
> 
> Michel.
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 29 Oct 2002 00:35:41 -0500

Mark,

Because we could not clearly define sin6_scope_ID its basically a void
in the base API now.  And IEEE did the same thing.  Works for
link-locals yes.  So if your DNS 2-face reqs that it won't work yet
because of lack of consensus on scoping and no one has implemented a
product for production networks today that use SLs.  I asked Richard to
speak up but until I hear from him I will assume that.

/jim

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, October 28, 2002 7:20 PM
> To: Keith Moore
> Cc: Michel Py; Margaret Wasserman; [email-masked]
> Subject: Re: Limiting the Use of Site-Local 
> 
> 
> 
> > > In a nutshell, the point you are trying to make is that RFC1918 
> > > addresses are bad because NAT exists.
> > 
> > no, that's missing the point.  use of RFC 1918 addresses in 
> a network 
> > that can also use global Internet addresses is harmful 
> regardless of 
> > whether that connection to the global Internet uses NAT or 
> whether it 
> > is merely via a router that filters traffic to/from the 1918 
> > addresses.
> > 
> > NAT is irrelevant to this particular problem. The problem is that
> > in the presence of either 1918 or SLs applications have to 
> deal with 
> > a mixture of scoped and global addresses without any good 
> way of knowing 
> > whether such an address is valid (and whether it means the 
> same thing) 
> > in the context of a particular node.
> 
> 	Which just means that we need to provide a way for the 
> application /
> 	library to return appropriate addresses.  Make SL work 
> rather than
> 	saying "kill them" or "don't put them in the DNS".
> 
> 	I've already said how to put them in the DNS.  It requires a new
> 	record but it will work and it will remove the need for 
> two faced
> 	DNS unless the sites *wants* to use two faced DNS to 
> hide the records.
> 
> 	Site locals provide a solution for a certian problem 
> space.  They
> 	do create additional problems but they are not 
> insolvable problems
> 	and are no different to the problems causes by LLs.
> 
> 	You need a function that looks up names and returns 
> addresses along
> 	with the scope_id.  We have that in getaddrinfo().  You need a
> 	function that takes a address and a scope_id and 
> returns the name.
> 	We don't have that but it is very easy to do that in 
> the DNS if you
> 	want to privided you have a scope-id to scope-name 
> function which
> 	is need.
> 
> 	e.g.
> 		<reverse-nibble>.<scope-name>  PTR <name>
> 	
> 	It's not zero-conf but sites will most probably never 
> be zero-conf.
> 
> 	e.g.
> 
> foo.example.net.  SA6 1080:0:0:0:8:800:200C:417A . 
> foo.example.net.  SA6 FE80:0:0:0:8:800:200C:417A 
> my-site.example.net. foo.example.net.  SA6 
> FEC0:0:0:0:8:800:200C:417A my-link.example.net. 
> c.0.0.2.0.0.8.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.0.
> 1.ip6.arpa. (
> 	PTR foo.example.net. ) 
> c.0.0.2.0.0.8.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.
> F.my-site.example.net. (
> 	PTR foo.example.net. ) 
> c.0.0.2.0.0.8.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.C.E.
> F.my-link.example.net. (
> 	PTR foo.example.net. )
> 
> 	and you have a local table that maps
> 	my-site.example.net and my-link.example.net to 
> appropiate scope-id
> 	values.
> 
> 	Now if you want to send address between applications in 
> binary format
> 	just send SA6 rdata instead of AAAA rdata.
> 
> 	Applications / libraries can filter out the addresses that are
> 	not useful to them if they want.
> 
> 	Mark
> 
> > > 2. site-local is bad because RFC1918 is bad.
> > 
> > sorry - the two are quite similar, and they cause similar 
> problems for 
> > apps.
> > 
> > > >> and a global address.
> > > 
> > > > please, elaborate.  I haven't seen a good one yet.
> > > 
> > > A somehow isolated subnet, where most hosts would have site-local 
> > > only addresses, except for a gateway or proxy that would 
> have both.
> > 
> > that's what 1918 was intended for.  again, I don't have a 
> huge problem 
> > with it as long as the apps don't have to deal with 
> multiple scopes - 
> > but experience with 1918 predicts that that's exactly what will 
> > happen.
> > 
> > > > you're missing the burden that having a mixture of SLs 
> and globals 
> > > > puts on apps.
> > > 
> > > You are missing the point, IMHO. This is not your call nor mine. 
> > > Site-local addresses do exist, been there for long, some 
> people will 
> > > purposedly choose to use them in combination with global 
> addresses. 
> > > As of today, the address selection draft addresses use of 
> site-local 
> > > and global addresses simultaneously and I do not see a reason to 
> > > change it.
> > 
> > IETF's job is to try to explain what will make the network 
> work well.
> > Imposing constraints on the use of SLs will help the 
> network work better.
> > If SLs are encouraged as in the current draft it will 
> degrade the ability 
> > of the network to support applications.  
> > 
> > Keith
> Mark Andrews, Internet Software Consortium
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 29 Oct 2002 00:43:31 -0500

Michel,

OK lets try to cut to the chase as they say.  Clearly in a mission
critical environment where lets say people are dead (I mean really dead)
because the network screws up.  It is wise to reduce the single points
of failure.  But that should not be done as Keith stated with separate
address space and I will add it can be done with global address space.
Any packet can prevented from leaving any network or one coming in with
absolute certainity.  There is no plug into the network.  That is what
most mission critical systems do.  Now to evolve those systems to use
data outside which is where they are going IMO.  That does not mean we
require SLs.  What it means is we need par excellence security.

I would rather spend my time working on that par excellence security
than using duct tape and band-aids to patch SLs together.

But to argue philosophically that the conclusion to these mission
critical environments requires a separate address space as a premise is
simply a false premise.  

The only reason 1918 was valid was because:

1. We did not have IP security in the works even as we do now.
2. We were paranoid about v4 address space with 2-to-the-32.

And then we got NAT.  

Lets not do this with Ipv6.

/jim

/jim

> Sent: Monday, October 28, 2002 7:45 PM
> To: Keith Moore
> Cc: Margaret Wasserman; [email-masked]; [email-masked]
> >> Michel Py wrote:
> >> Let's talk about an airplane's IPv6 internal systems. 
> There will be a 
> >> requirement that the rudder's embedded controller reacts to 
> >> site-local only, just in case a bozo mixes up something. OTOH, the 
> >> NAV computer does need to talk to the outside word to 
> extract weather 
> >> or other in-flight dynamic data and to report to ground.
> 
> > Keith Moore wrote:
> > that's what packet filtering is for.
> 
> Keith, you don't get my point. The requirement for site-local 
> is because someone or something can mess up packet filtering. 
> It is in *addition* of the packet filtering. In an airplane, 
> one level of security does not take off.
> 
> Michel.
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 29 Oct 2002 01:16:56 -0500

Brian,

The argument that globals don't benefit firewalls is not true. In
Digital we ran globals company wide and now in HP.  The Firewall is
there for sure.  But the algorithms are to check security parameters
coming in and other filtering rules the translation and mappings and
data structure lookups and the duplicate data paths are not needed. In
addition with Ipsec it will make the firewalls even faster because now
all the many filters are not needed because the SA between two nodes or
an extranet router can do Ipsec verification.

So the technical ability of globals to pass through firewalls is far
better and I believe an order of magnitude not just basic perf gain.

In addition philosophically private addresses are simply not wise. But
won't go there yet again.  But IPv6 does not need SLs today at all and
they definitely should not put large mission critical operations at risk
with IPv6 at all.

/jim

> From: Brian Zill [mailto:[email-masked]] 
> Sent: Tuesday, October 29, 2002 12:59 AM
> To: Margaret Wasserman
> > Margaret Wasserman writes:
> > 
> > Private addressing does not provide any time of security that
> > cannot be obtained (and more easily, in most cases) by 
> > appropriate configuration of firewalls or filters on routers.
> 
> So are you advocating that people use global addresses with a 
> firewall and/or filters to block outside connectivity for 
> part of their address space?  Doesn't that just create a 
> weird form of private address space? And worse (since it is 
> not officially sanctioned) one that applications can't recognize?
> 
> One advantage of having scoped addresses defined in the IPv6 
> architecture from the start is that applications can know not 
> to pass them outside of their scope.  If we instead suggest 
> that people firewall/filter off random portions of the global 
> address space, then apps will blindly pass those addresses 
> around in the data stream, mistakenly thinking that they are 
> real global addresses.  Only having dedicated scoped address 
> space allows apps to do the right thing.
> 
> --Brian
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 29 Oct 2002 01:21:41 -0500

ICMP messages are for a purpose if we remove SLs they will be used as
today which we understand to manage and operate networks.  That is not
the case for SLs.

Your arguing that apples and oranges are the same logically and they are
not and have completely different properties.  In fact SLs have other
properties that cause network failures too.  Too many quite frankly.
And many of us have known this for years.  Maybe now that it is being
discussed in an operational WG we can put some controls on them till we
better understand them.

/jim

> Sent: Tuesday, October 29, 2002 1:16 AM
> To: Bound, Jim
> > Jim Bound writes:
> > A node could send to a dst addr with less scope in its src. If the 
> > packet goes far enough it can never return.
> 
> The packet will hit a router which will refuse to forward it. 
>  This is exactly the same as a node sending a packet with 
> inadequate hop count to reach the destination.  In both cases 
> the sending node gets back an ICMP error message (scope 
> exceeded or hop count exceeded).  There is nothing strange here.
> 
> --Brian
> 
>

---

From: "Brian Zill" <[email-masked]>
Date: Mon, 28 Oct 2002 22:16:11 -0800

> Jim Bound writes:
>
> A node could send to a dst addr with less scope in its src.
> If the packet goes far enough it can never return.

The packet will hit a router which will refuse to forward it.  This is
exactly the same as a node sending a packet with inadequate hop count to
reach the destination.  In both cases the sending node gets back an ICMP
error message (scope exceeded or hop count exceeded).  There is nothing
strange here.

--Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 29 Oct 2002 07:59:49 -0500

Here is some more information from my unpublished document on
site-locals.  Maybe after Atlanta I'll finally get around to
publishing it...

This section concerns the suppose advantages that IPv6 site-local
addresses have for long-lived connections (please debunk if I'm
mistaken!).

Margaret

     A much-touted advantage of site-local addressing is that it will
     allow site-local, long-lived IPv6 connections to survive
     renumbering of global prefixes.  Global prefix renumbering could
     happen when an organization switches from one ISP to another, or
     when an ISP renumbers its internal network, changing the prefixes
     assigned to customers.

     There is, however, a potential risk to using site-local addresses
     for long-lived connections.  Those connections may fail when a site
     becomes partitioned, even if global connectivity is still available
     between the partitions.

     To make a wise decision about whether to use site-local or global
     addresses for long-lived intra-site connections, it is necessary to
     weigh the expected frequency of renumbering against the expected
     frequency of site partitioning.  Since the frequency of these
     events will vary widely between sites, there is no single answer
     that would be best for all sites.

     It should also be noted that there are many reasons why a long-
     lived connection might fail, including network outages, system
     restarts or local network reconfiguration.  Any application that
     depends upon the reliability of a long-lived connection will still
     need to include a mechanism to re-initiate a lost connection.

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 29 Oct 2002 08:24:08 -0500

A couple of people have asked off-line, and I thought it would be good
to clarify...

_None_ of my mail on this thread (or the previous Node Requirements
thread) has been made in my "official" capacity as a WG chair.  I'm
just stating my personal opinions about the technical issues with
site-locals and what I think that the WG should do.

In the end, I will abide by the consensus opinion of the WG regarding
these issues, even if the WG doesn't agree with me (as you often
don't :-)).

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 29 Oct 2002 10:39:56 -0500

>First, because it's not productive to revisit old design decisions.
>Scoped addresses and the notion that nodes would have multiple addresses
>of different scopes are design decisions from many years ago.

I can understand this argument, but I don't think it fully applies
here...

We did decide to include site-local addressing in the architecture
years ago, but only fairly recently did we start documenting how
it would actually _work_.

The scoped addressing architecture is still an I-D (not any sort
of RFC), and I think it is appropriate to consider (and even
re-consider) the architecture described in that I-D.

>Second, scoped addresses are an important part of the IPv6 architecture
>because they reflect today's internet architecture. The internet is no
>longer a fully-connected network of nodes with static addresses. (I get
>the impression that some participants in this thread would like to turn
>the clock back 20 years!) The world is more complicated now. Sites have
>strong boundaries; firewalls and two-faced DNS are commonplace for
>enterprise networks. Addresses occasionally change.

I think that one of the goals of IPv6 is to enable the simplification
of the Internet architecture.  Maybe this is naive and idealistic, but
I hope that, when we turn the clock forward 20 years, we'll find a
flatter and simpler Internet architecture than we have today, enabled
by IPv6.

One way that I think we could help to make this change is be advocating
the use of globally-unique addresses on private networks.

>The idea of restricting site-locals to completely disconnected networks
>doesn't make much sense to me. It's like saying you can have them but
>not really. How would we handle intermittently connected sites, or
>partially connected sites? What would happen when a network that is
>using site-locals gains global connectivity? This seems like a recipe
>for encouraging v6 NAT, which is not something we want.

These are valid questions/concerns, and I think it makes sense to
discuss them.

However, I'm not sure that we know the answers to all of these questions,
even if site-locals are used side-by-side with global addresses.  How
would that work for intermittently connected sites?  Partially-connected
sites?  Sites that gain global connectivity?  Sites that renumber?  Etc.

One of the issues with having a "tool" like site-local addressing is
that it is easy to see it as a panacea to solve a huge number of problems.
In actuality, site-local addressing will not solve the bulk of the
problems you've listed without other things also being defined -- like
explicit support for site-locals in applications, and in the DNS.

>In my opinion, IPv6's explicit architectural support for multiple
>addresses and scoped addresses are two of its advantages over IPv4.
>Because they're baked in from the start, applications can do the right
>thing with scoped addresses. And one way or another they will be there
>eventually (look at how scoped addresses have crept into IPv4), so it's
>better if applications that need to know about them are coded that way
>from the start.

Unfortunately, I don't think that most IPv6 applications are (or will
be) coded from scratch.  In general, folks are trying to port IPv4
applications, and the need to understand all of the issues surrounding
site-local addresses will represent a significant hurdle and/or be
ignored -- both of which are bad.

Margaret

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 29 Oct 2002 15:23:16 -0500

I simply have completely different data but will go check with friends
at Boeing and be back.

/jim

> Sent: Tuesday, October 29, 2002 12:21 PM
> To: Bound, Jim; Margaret Wasserman; [email-masked]
> [For the record, Internet access for passengers is a 
> completely separate system that does not connect to the 
> plane's systems, and here's the reason why: Imagine a bunch 
> of IETFers in a plane. We all have laptops. Give us an 
> Ethernet link to the plane, someone will hack the plane just 
> to pass time during a long flight. Sounds like suicide to me....]
> 
> > Jim Bound wrote:
> > here is not reason at all why what you stated could not
> > be link-local addresses.  I would argue if sensors do what
> > I hear they will do link-locals are fine and we do have controls on 
> > that and they are not forwarded off the link.
> 
> That's not the way it works. In the rather classic triple or 
> quintuple system redundancy, each of the devices that can 
> control something is on a separate bus (a separate subnet). 
> But it might talk to the other two or four all the time, and 
> they occasionally vote and might decide that one of the 
> devices is out of whack, things like this. So, there are 
> multiple links in case of cable failure or jabbering NIC or 
> something, but they might talk to each other. Site-local.
> 
> >  The cockpit and intra-connections could be viewed as on 
> link easily. 
> > Access to the FAA or GPA Sat-Com would require global (hmm maybe 
> > inter-planetary scope :--)) and as in my previous mail 
> those would be 
> > gateways to the sensors.
> 
> But the plane itself would not be completely isolated either. 
> Let's face
> it: directly or indirectly there is almost no network today 
> that is not connected to the Internet not even a plane in 
> flight. So saying that SLs can not be used in networks that 
> are connected to the Internet is the equivalent of killing them.
> 
> Same as the other examples I used before: sensors/control 
> devices in a metropolitan water distribution system, or in a 
> power grid. SLs are a perfect choice for these, and somewhere 
> in that network there will likely be a host that has access 
> to the Internet as well.
> 
> These topics have been discussed years ago, and I question 
> why we need to revisit this.
> 
> Michel.
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 29 Oct 2002 15:44:36 -0500

Tony,

I support that.  We do need to hear from the network managers I agree.
But I do think we need controls pretty soon.

/jim

> From: Tony Hain [mailto:[email-masked]] 
> Sent: Tuesday, October 29, 2002 2:37 PM
> To: Bound, Jim; [email-masked]
> Bound, Jim wrote:
> > So if I read your view.  Your saying.  Control them but do
> > not revoke them?
> > 
> > The question is can we control them then right?
> > 
> 
> I was trying to say; comment on known problem areas, but 
> nothing more. This is because we can't control their use, and 
> even if we could, we might be cutting of a valuable service 
> down the road. When we know there is a problem, like the use 
> of SL with the current single scope DNS servers, we should 
> point out the reasons developers should think twice before 
> going there. 
> 
> > But if we can't figure it out or agree then that could be revoke?
> 
> No. There are deployment models where SL is what the network 
> manager wants, but those who are complaining on this list are 
> not working in networks with those models. Before any 
> discussion about removing them can take place, the people 
> that want to use them need a voice.
> 
> Tony
> 
> > 
> > I would hope we can control and not revoke.
> > 
> > But as you know I don't believe they should have ever been
> > permitted in the first place in IPv6.  Site-Locals and 1918 
> > are BOGUS that is not how to control what they wanted to do 
> > in the first place.  
> > 
> > /jim
> > > From: Tony Hain [mailto:[email-masked]]
> > > Sent: Monday, October 28, 2002 2:47 PM
> > > happens operators of networks that actually use 1918 
> space need to 
> > > be engaged to find out their requirements.
> > > 
> > > switches to only support SL/LL rather than potentially multiple 
> > > global prefixes. There is no reason for those devices to interact 
> > > across a scope boundary, so the peer nodes that may also 
> need global 
> > > access MUST keep their SL to interact in the limited scope.
> > > 
> > > Tony
> > > 
> > > 
> > > 
> > > 
> > > 
> > >

---

From: "Michel Py" <[email-masked]>
Date: Tue, 29 Oct 2002 12:59:55 -0800

Boeing is not the only aircraft manufacturer in the world....

-----Original Message-----
From: Bound, Jim [mailto:[email-masked]] 
Sent: Tuesday, October 29, 2002 12:23 PM
To: Michel Py; Margaret Wasserman; [email-masked]
Cc: [email-masked]
Subject: RE: Limiting the Use of Site-Local

/jim

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Tue, 29 Oct 2002 22:14:52 +0100

>      becomes partitioned, even if global connectivity is 

=> FWIW, I think that one can see this as an advantage.
An admin might not want these connections to survive
when going through the Internet (outside the site). 
When the site was partitioned, an admin could have forgotten
about these connections (?) and using site-local helped
made this obvious. As opposed to having (potentially)
sensitive data going over the public net. 

Just another way of thinking about this...

Hesham

---

From: Mark Smith <[email-masked]>
Date: 30 Oct 2002 09:14:15 +1100

On Wed, 2002-10-30 at 08:29, Richard Draves wrote:
> > about these connections (?) and using site-local helped made 
> > this obvious. As opposed to having (potentially) sensitive 
> > data going over the public net. 
> 
> Yes of course that's an advantage. I can't imagine anyone (from
> enterprise network administrator to home user) wanting intra-site
> communication to suddenly be routed outside the site.
> 

Surely there would be a both a sink route in your border routers for
your own /48 global address ranges, and source address access list
facing the Internet, preventing this from happening. This is common
security practice.

> Rich

---

From: "Michel Py" <[email-masked]>
Date: Tue, 29 Oct 2002 17:15:35 -0800

I am in complete agreement with Tim Hartrick's last posting.

Michel.

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 30 Oct 2002 22:16:48 +0100

> > => I guess you would give the same answer
  > > for link-locals and many other cases. 
  > 
  > link-locals are there for autoconfiguration, not security.

=> You said that if you want forward site-locals beyond
a site then create a tunnel and I said:

      I guess you would give the same answer
  > > for link-locals and many other cases.

I didn't say anything about site-locals and security
and I didn't ask what link-locals are for. I said
that you can create a tunnel to take link-locals
beyond a link, so the problem is not specific to
site-locals.

  > 
  > > So, if you have a tunnel, secure it. 
  > 
  > answer is non-responsive.  we were discussing unauthorized
  > router modifications.

=> It's responding to the comment that site-locals
can be forwarded beyond the site if a tunnel is created.

  > 
  > site locals do not result in a meaningful improvement in 
  > security to a
  > site of nontrivial size -- any node with a global address may
  > unilaterally "choose" to extend the site...

=> I was not debating this point. But I agree that if a node
inside the side wishes to extend it, it can do that. 
It can also do that if it tunnels IP packets in HTTP.
So this is a different scenario (having a 
"malicious" node inside the site).

Hesham

  > 						- Bill

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 30 Oct 2002 22:47:10 +0100

> :-)
  > 
  > Sorry if my note seemed condescending or something... I
  > didn't mean it that way.

=> oh no I didn't interpret it that way, I just wanted to
make sure that we talk about the same thing.

  > >The point was: using tunnelling to evade scope boundaries.
  > >This can be done in a zillion ways for different addresses,
  > >if we're not careful how the tunnel is setup or if a malicious
  > >node is inside the site and can fool the firewall (if one exists).
  > 
  > I completely agree...
  > 
  > The current discussion is (I think) attempting to compare the
  > security implications of two ways of addressing a private
  > network:
  > 
  >          - Using site-local addresses that are filtered at
  >                  an SBR due to site configuration.
  >          - Using global addresses that are filtered at the
  >                  border of the private address space using
  >                  routing filters.
  > 
  > In neither case would the addresses being used on the private
  > network appear in global routing tables.
  > 
  > I still don't really understand why these cases are substantially
  > different in terms of security... 

=> I think that if you put Tony Hain's email together 
with Rich Draves' last email, you would get a good
idea about why it's better and what the "default"
should be. I think they both make sense. 

For a host, I think that the default should be 
1 site per interface. 

Not that I'm claiming to be
  > a security expert or anything, but I would like to understand
  > what the difference are, if any.

=> Sure, I think most of the mails on this thread are
clarifying this. 

Hesham

---

From: "Michel Py" <[email-masked]>
Date: Wed, 30 Oct 2002 15:25:02 -0800

Margaret,

> Let me turn the question around...  You have posited
> that the use of site-local address is somehow more
> "secure" than using a private global address range
> that is filtered in the router. Why?  What attacks
> would work in the latter case that wouldn't work in
> the former case?

I consider more secure if there is one more box to hack in order to
compromise the network.

Example:
A host has been compromised by installing a piece of software that reads
records from a database and "tunnels" the data out by embedding it in
dummy http requests sent to a special http server. No firewall that I
know of will catch this, so you prevent that host form accessing the
outside by configuring an access-list somewhere denying http access to
the outside.

a) the host has a PA address: remove that access-list, and your little
Trojan is ready to dump all the data out.

b) the host has a site-local address: Now you need something else,
another tunnel. You still need the Trojan to "tunnel" the database
information into http requests, but now you also need something like a
GRE or IPIP tunnel to tunnel the site-local addresses into PA.

Every security architect that's worth its weigh in dung will design the
network in such a way that the router that would be a good candidate to
configure a tunnel (most likely the SBR) on is not the same that the one
that holds the access-list, they are not administered by the same
personnel who have been explicitly promised court martial and jail if
they ever leak a password to a colleague. One more device to hack, more
work for the hacker, more secure.

Not to mention that in many cases the edge device is a Cisco, which
means for most mortal hackers that their choice in tunnel types is
limited by what is available in IOS, which in turn means that it will be
doable to block these tunnels in the upstream firewall, which in turns
means that the firewall itself will have to be hacked as well. Yet
another device to hack, even more work for the hacker, even more secure.

Another reason why site-local addresses are more secure: The hacking
requires more skill than removing an access-list. Remember, hacking is
mostly done from the inside. There is nothing the security engineer can
do to prevent a spy to be hired as a network engineer, that's why there
are security clearances. However, there is something that the security
engineer can do, is to make the job of the janitor-turned-spy impossible
by requiring a level of skill that he does not have. It's one thing to
get someone to memorize a command to type when nobody looks, it's
another thing to get someone to configure a router.

Conclusion: If configured properly, a network that implements
site-locals is more work for the hacker, and also requires a level of
hacking skill that is above acquiring the password of a router and
typing "no ip access-group xyz".

Margaret, we have been having this kind of discussion since 1993 when
RFC 1597 was being written.

Also, read please read Tim Hartrick and Richard Draves' excellent (as
always) posts.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Wed, 30 Oct 2002 16:33:38 -0800

>> Mark.Andrews wrote in response to Keith:
>> ... Your responses to this and previous
>> mail make me think that you are not actually paying
>> attention to what is being sent.  Rather you are
>> locked in a crusade to kill SL and are ignoring
>> anything which will actually address the problems
>> you raise.

> That summarizes it well.

Ditto.

Michel.

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 31 Oct 2002 00:13:20 -0500

Ole,

Question:  So what would you suggest in wording that we can provide to
state that this should be the case to prevent any notion of SLs being
forwarded in our specs.  Rather than just trust the good intentions of
suppliers?  That might be the BCP.  But we cannot leave it as it is per
this discussion.  I would like to not have it again on the list.  

What is your suggestion?

thanks

/jim

> From: Ole Troan [mailto:[email-masked]] 
> Sent: Wednesday, October 30, 2002 6:31 PM
> To: Jun-ichiro itojun Hagino
> Cc: Richard Draves; [email-masked]
> >>> A router might (and probably should) be hard-coded not to
> >>> forward link-local packets, as there is no reason to ever 
> >>> forward them.
> >>> 
> >>> However, a router that might ever need have multiple
> >>> interfaces in a single site can't be hard-coded not to 
> >>> forward site-locals. Whether or not they will be forwarded is 
> >>> the result of configuration.
> >>
> >>Actually, a router can forward link-locals between 
> interfaces on the 
> >>same link. In particular, a router can forward a packet with 
> >>link-local dest and/or source back out the interface from which it 
> >>arrived (and presumably generate a Redirect too).
> >>
> >>If you are implementing link-locals properly, it's really 
> very little 
> >>additional code to support site-locals. At least that's my 
> experience.
> >
> > 	could you comment on routing code? (RIPng, OSPFv3)  i 
> still think
> > 	it's way too tough to support multi-sited node.
> 
> RIPng is relatively simple. link-state protocols require 
> congruent areas and sites. there are some open issues with 
> regards to multicast and PIM I believe. routing protocol 
> support is required in any case for VPNs.
> 
> site-locals can be used without multi-site support, i.e 
> treated pretty much like globals. multi-sited-ness shouldn't 
> be recommended for other reasons than adding complexity to 
> routers, e.g DNS issues.
> 
> /ot
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 31 Oct 2002 00:35:34 -0500

I talk people out of using them at least once every two weeks as I get a
lot of mail on this.
I did have one case where they made sense.  A factory floor where they
have no connection to the outside for robotics.  The reason was they did
not want to mess in the architecture of this part of the network with
asking for IPv6 addresses.  In that case they can use IPv6 without an
ISP or paying for the address and getting one.  Or managing this space.

But most people want both global and site and when I am done they just
want global. 1918 was not digested in a pure form (if one existed) but
in a brain dead form and gave many users the wrong impression.

/jim

> From: Keith Moore [mailto:[email-masked]] 
> Sent: Wednesday, October 30, 2002 8:11 PM
> To: Bound, Jim
> Cc: [email-masked]; Tim Hartrick; 
> [email-masked]; [email-masked]
> > I would also ask all those who want to kill SLs turn your 
> support to 
> > Margaret to put the controls on.
> 
> Yes, this is the position I support.
> 
> Even I do not expect to kill SLs in the sense that we would 
> reallocate those addresses for other purposes, forbid using 
> them under all 
> conditions, expect routers to always filter them or hosts to always
> ignore them, etc.   I don't like pulling the rug out from under
> people who have built designs around them, even if I think 
> their designs are shortsighted and/or naive.  
> 
> I do however think we need to discourage use of SLs except in 
> isolated networks.  
> 
> I also think we need to make it clear that in general applications 
> aren't expected to work in the presence of a mixture of scoped and 
> global addresses.  Applications should treat SLs exactly like 
> global addresses. 
> 
> Finally I think we need to discourage the idea that SLs are a 
> security mechanism, because SL filters are at best only 
> marginally better than other kinds of address filters (and 
> I'm being charitable there).
> 
> Keith
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 31 Oct 2002 00:30:38 -0500

002 10:59:45 +1100, Mark Andrews wrote:
> > 
> > 	I'm talking about 1 name with multiple addresses being
> > 	returned in multiple scopes.  I'm taking about having
> > 	getaddrinfo() then filter out the inappropriate addresses
> > 	using local knowledge and setting sin6_scope_id.
> 
> Via this mapping table thingie, which I suppose we could 
> configure easily enough using DHCPv6.  So what happens when 
> the mapping table isn't configured, is misconfigured, or 
> somebody passes a raw scoped IP address into some other scope?

In a mission critical network an error like this could mean someone is
dead for one thing.

The above assumes DHCPv6 would have the knowledge of the network or we
would need new options to negotiate SLs and topology in general.  That
will take awhile to parse IMO in the WG and here.

/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 31 Oct 2002 00:28:01 -0500

> I'm guessing you mean an interface can only be in only one 
> site at a time, but not necessarily all members of the same site.

But this is not an axiom we all have consensus on in any spec?  As I
said Brian Haberman had this but we did not bless it.  And the AD's
don't bless that spec yet either.

This is what we need stated. 

/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 31 Oct 2002 00:41:48 -0500

I think Brian should do this on the agenda as a necessity.  Lets here
from someone who can tell us how they implemented it and also is a
routing engineer and obviously can disclose to us details which I know
well we cannot always do here in public.

This should be a priority agenda item not to kill SLs but to learn from
this implementors experience.  Now I am sure my colleagues on either
side do not disagree that this is important.

I also think Mark speaking on his DNS methods would be of value too.  As
the DNS part is quite important.

In fact lets have a technical meeting on issues and not status updates
of drafts.

/jim

> From: Brian Haberman [mailto:[email-masked]] 
> Sent: Wednesday, October 30, 2002 9:02 PM
> Jun-ichiro itojun Hagino wrote:
> > 
> Not that the chairs have finalized the agenda, but I am 
> planning on presenting what it took me to get a site-border 
> router coded and running.  If you want to request a certain 
> level of detail, let me know.
> 
> Brian
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 31 Oct 2002 00:44:30 -0500

Brian,

I would be also interested in the conditionals in this which is best
case 3 machine instructions too.  And what the conditionals did to the
complexity of the code and future maintance.  Of course I am not clear
implementation details interest many these days in our decision process.
Its like we infinite time and infinite resources to do IPv6.

/jim

> Sent: Wednesday, October 30, 2002 9:08 PM
> To: Ole Troan
> Cc: Jun-ichiro itojun Hagino; Richard Draves; [email-masked]
> Ole Troan wrote:
> > RIPng is relatively simple. link-state protocols require congruent 
> > areas and sites. there are some open issues with regards to 
> multicast 
> > and PIM I believe. routing protocol support is required in any case 
> > for VPNs.
> 
> The actual routing protocol changes in RIPng is dependent on 
> how you structure your RIBs.  I hacked RIPng to make an SBR 
> using a monolithic RIB with an additional index (the zone 
> id). It was an additional 800-900 lines of code to deal with 
> figuring out which RIB entries needed to be advertised on 
> each interface.
> 
> Then there are the changes to configure and maintain the zone IDs.
> 
> The biggest hit is actually in the forwarding.  Each packet 
> gets at least one additional table lookup (for the incoming 
> zone id).  Then there are the checks to ensure that the 
> source address is valid (e.g. a site-local SA and global DA 
> trying to cross a site border).
> 
> The extra cost?  Performance drops around 25-30% for a SBR 
> between 3 sites.  Of course, this was all software based, but 
> even a hardware-based solution will take the extra lookup hits.
> 
> Brian
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 31 Oct 2002 00:38:06 -0500

I agree and it was a personal attack and you should get an apology as
all your arguments have been technical challenges.  The remark was out
of line. 

Keith - the rule I use on that one is I confront them directly in person
at the IETF when they do that about their behavior.  And I find more are
much more bold in email than in person.
I am sure you will handle it much better than I would in person :---)

/jim

> Sent: Wednesday, October 30, 2002 8:12 PM
> To: [email-masked]
> and it appears to me that you are trying to attack me 
> personally rather than actually make credible arguments in 
> favor of using SL.

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 31 Oct 2002 00:52:32 -0500

Michel,

> > What is a Monica strike?
> 
> A Monica strike is what Bill Clinton did a while ago: Make a 
> lot of noise launching a bunch of cruise missiles at Saddam 
> to try to get the people's attention away from the fact that 
> he had a young lady under his desk.

If your at this upcoming IETF I would love to speak to you about this statement in person OK.
So lets go offline and figure out when we can meet.  How about the Hard Rock Café one night.
I would love to delve deeper into your knowledge of the inner workings of one of our Presidents.  Of course I will share my opinion of your statement but only to you and in person just btw us ok.  Also I was not a supporter of this President but he was the President.
Mind if I bring a couple of Gulf War Veterans I can probably locate in Atlanta?

But we digress.  And apologize to the list but had to respond.  I will stop here.

Look forward to seeing ya guy,
/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 31 Oct 2002 00:56:58 -0500

Silly me too.  I thought valuing differences was part of our jaundra in
the IETF and I am on the right side of things too.  Oh well I learn
everyday.

/jim

> Sent: Wednesday, October 30, 2002 9:47 PM
> To: Michel Py
> Okay, so I am confused how it applies here.
> 
> I'd be very surprised to learn that I have a young lady under 
> my desk...
> 
> Margaret
> 
> 
> At 09:32 PM 10/30/02, Michel Py wrote:
> > > What is a Monica strike?
> >
> >A Monica strike is what Bill Clinton did a while ago: Make a lot of 
> >noise launching a bunch of cruise missiles at Saddam to try 
> to get the 
> >people's attention away from the fact that he had a young lady under 
> >his desk.
> >
> >Michel.
>

---

From: "Michel Py" <[email-masked]>
Date: Thu, 31 Oct 2002 08:04:56 -0800

> If your at this upcoming IETF I would love to speak to you
> about this statement in person OK. So lets go offline and
> figure out when we can meet.  How about the Hard Rock Café
> one night. I would love to delve deeper into your knowledge
> of the inner workings of one of our Presidents. Of course I
> will share my opinion of your statement but only to you and
> in person just btw us ok.  Also I was not a supporter of
> this President but he was the President. Mind if I bring a
> couple of Gulf War Veterans I can probably locate in
> Atlanta?

Have you ever heard the word "humor"? besides, I did not invent the expression, as this is an American topic and I am not American.

You might want to to talk to press cartoonists instead.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Thu, 31 Oct 2002 08:25:24 -0800

Talking about etiquette, not posting HTML to the list would be a good beginning.

Michel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 31, 2002 8:12 AM
To: Michel Py; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Limiting the Use of Site-Local

 I'm wondering what on earth this has to do with the scope of this mailing list. 
 And a lesson in etiquette is reserved for our non-American friend, Mr. Py. Please pick up the white courtesy phone.

---

From: "Michel Py" <[email-masked]>
Date: Thu, 31 Oct 2002 08:17:27 -0800

> Gary Allmond wrote:
> The use of site-local is a great proposal. What I think should
> be done is just like in the IPv4 world, reserve a block (or a
> couple of blocks) of numbers that are non-routable. This will
> allow companies to know what nubers they are to use when
> setting up site-local numbers based on the number of devices.

Thank you.

Michel.

---

From: [email-masked]
Date: Thu, 31 Oct 2002 11:12:12 -0500

I'm wondering what on earth this has to do with the scope of this mailing
list. 
 And a lesson in etiquette is reserved for our non-American friend, Mr. Py.
Please pick up the white courtesy phone.

-----Original Message-----
From: Michel Py [mailto:[email-masked]] 
Sent: Thursday, October 31, 2002 11:05 AM
To: Bound, Jim; Margaret Wasserman
Cc: [email-masked]
Subject: RE: Limiting the Use of Site-Local

> couple of Gulf War Veterans I can probably locate in

Have you ever heard the word "humor"? besides, I did not invent the
expression, as this is an American topic and I am not American.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Thu, 31 Oct 2002 09:27:37 -0800

> couple of Gulf War Veterans I can probably locate in

Someone tells me that you need to rent a movie called "Wag the dog".

Michel.

---

From: "Richard Draves" <[email-masked]>
Date: Thu, 31 Oct 2002 09:47:18 -0800

> Obviously my last two models don't really fit the idea that 
> site-local addressing is to cover a single geographical site.

Why do you think that site-local addressing is tied to geography in any
way?

Rich

---

From: "Michel Py" <[email-masked]>
Date: Thu, 31 Oct 2002 18:04:29 -0800

Michel Py
>> Keith, what you are saying here is that the utility
>> company is going to have to use PA addresses, that it
>> does not own, to configure tens of thousands of devices
>> on thousands of subnets, and be forced to renumber
>> if they want to switch ISPs, even though these devices
>> have nothing to do with the public Internet, just
>> because you don't like SLs.

> Kurt Erik Lindqvist wrote:
> ....and the day the utility company decides to outsource the
> monitoring they will have to renumber to global addresses
> anyway.

Total nonsense.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Thu, 31 Oct 2002 19:00:23 -0800

> To prove Keiths point, just look at how often any of
> the RFC1918 addresses occur in the global routing
> table. This is despite the fact that they are not
> supposed to be routed.

That's fine by me, anybody who tries to get to mine will get to the bozo
that forgot to filter them instead.

Michel.