Subject: RE: C000

From: "Michel Py" <[email-masked]>
Date: Tue, 15 Apr 2003 09:50:55 -0700

> Pekka Savola wrote:
> Invent a prefix.

You mean, hijack a prefix. No thank you. Been there, done that, been
killed by it. There have been enough opinions voiced against doing this.
Hijacking is not an option.

Michel.

--------------------------------------------------------------------
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: Pekka Savola <[email-masked]>
Date: Tue, 15 Apr 2003 21:24:22 +0300 (EEST)

On Tue, 15 Apr 2003, Michel Py wrote:
> > Pekka Savola wrote:
> > Invent a prefix.
> 
> You mean, hijack a prefix. 

Yes.

> No thank you. Been there, done that, been

What we'd need, rather than opinions, is documentation and analysis what
has actually happened and why.

There seem to be three main issues here:

 1) set-up
    - "which prefix should I pick?"
    - "where must it be configured?"

 2) dealing with the introduction of Internet connectivity
    - sooner or later, the will be *some* network connectivity, even if 
intermittent.  Otherwise, there are zero problems with prefix hijacking.
    - "getting basic things to work"

 3) reconfiguring all the instances where invented prefix was used
    - "finding out all the cases where it has been configured and 
changing them"

 4) a non-problem: forcing the Internet to accept your hijacked prefix.  
This is specifically not an issue, as the assumption is that this is not 
acceptable.

Note: in today's world, it seems to me that almost all of these cases are
really those of intermittent connectivity.  Can even a small "dentist's
office"  really manage without a model/ISDN dialup, for reading email, or
some other minor other business.

A particular problem seems to happen in the case where one consultant sets 
up a network with hijacked prefix and another comes, much later when 
everything has been forgotten, to change/fix something.

HOWEVER, remember that we're talking about "dentist's office" case: a
single link which has zero connectivity.  No external parties all over the
Internet; only a node or two on the local link.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Robert Elz <[email-masked]>
Date: Wed, 16 Apr 2003 03:02:58 +0700

Date:        Tue, 15 Apr 2003 21:24:22 +0300 (EEST)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  |  3) reconfiguring all the instances where invented prefix was used
  |     - "finding out all the cases where it has been configured and 
  | changing them"

But this is what doesn't happen - and it is exactly what sites want to
avoid - they want addressing that doesn't alter, at least for internal
uses.   So, even assuming it is trivially easy, they won't change them.

  | Note: in today's world, it seems to me that almost all of these cases are
  | really those of intermittent connectivity.

Of changing connectivity, whether intermittent, or not.   Right now
(as of this instant I mean) my connections rarely last much more than
an hour or so (then restart fairly quickly).   Every time I connect I
get a different address.   You can be dead sure that that address has
no bearing at all on the addressing I am using on my internal net.

We might like to pretend that we can stop providers from doing that, but we
cannot.

  | HOWEVER, remember that we're talking about "dentist's office" case: a
  | single link which has zero connectivity.  No external parties all over the
  | Internet; only a node or two on the local link.

No.   That's one scenario.   Another is a link which is normally connected,
but where the router just happens to be down (maybe the router is a linux
system and the thing has crashed...).   There, there's nothing to hand out
prefixes to other nodes, so all they're going to get are LL addresses.

There's too much "I know how the net should be used, anyone who dreams of
using it differently than I think should be done is brain dead" type stuff
going on here.   Learn to accept that people will use things in all kinds
of ways that none of us can imagine right now.

In another message [email-masked] said:
  | You miss my point completely.
  | I'm worried about the specification complexity.  Implementation complexity
  | is important of course, but was not the point here. 

Specification complexity of SL is almost zero.   It has been that way for
ages.   And implementations were using it regardless.   What's more the
degree of specification was just about perfect for this.   The aim and
basic rules were there, and that was it.   Enough to work out what needed
to be accomplished.

With that, implementors can go and try different ways of actually using
the things, documenting the results along the way for the benefit of others.

  | We need to ensure no significant amount of *IETF* work is wasted on making
  | site-locals "work".  The easiest way to do that seems to be "deprecating"
  | them.

There's been far more IETF work spent (it seems to me) in the past few
months on the attempt to deprecate site locals than was ever spent on their
specification, or on making them work.   This hardly seems to have been *easy*.

All that was needed was to do nothing, and see what happens.

That's still all that is needed.

kre

ps: with this, enough from me for a day (or more perhaps).

---

From: Robert Elz <[email-masked]>
Date: Thu, 17 Apr 2003 16:49:12 +0700

Date:        Wed, 16 Apr 2003 13:47:36 +0300 (EEST)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | Please note that the discussion was about "disconnected" case -- and for
  | that only.  Ensuring stable internal connectivity etc. is a different 
  | beast altogether.  What I tried to do is to scope issues in the case that 
  | site *is* actually disconnected -- and a special single-subnet case of 
  | that in particular.

The problem is that when you divide up the problems into neat little
compartments, and try to solve each one separately, the mess that
results when you try and combine it all back together again is far
worse than anything we have today.

  | Assume that the system is is quite simple, and changes could be done by 
  | knowledgeable person in less than 10 minutes.

Sure (I know others will never assume that would ever be possible, but
I am willing to assume that eventually we can make renumbering quite
painless).

  | Assume that the system would get a stable global prefix from the ISP.

I'm not sure I'd assume that.   In fact, I think it would be unlikely.

  | Why would it want to keep its invented prefix?

Why would it want to change?

  | Keeping it would actually 
  | hurt them too as it would be used in the source address selection and 
  | about a half of their packets would get return routed to /dev/null or some 
  | other site.  They'd certainly want to renumber.

You're making assumptions about what you'd want, and applying them to
others.

If my invented address is 8123:4567::whatever then source address
selection isn't going to be a problem, anything to a 2000::/3 address
will pick whatever 2000::/3 address my ISP has supplied me just now.

Anything to my 8123:4567::/32 address space will use that address as
source.

All looks like it will work fine to me - and painlessly avoid having
my internal connections break.

Of course, so does fec0::/10 in just the same way, with the advantage
that what is going on with that address is known by everyone.

  | That was the specific scenario here (I think).  I didn't claim to analyze 
  | all the SL scenarios.

You're in favour of deprecating the things without analysing all scenarios?

  | I agree that we can't force a model on people -- but then again, we *can* 
  | try to look at which models people have, and try to design solutions for 
  | that.

Sure.   And while doing so, let's look for a unified model which suits
all the purposes if we can, it keeps everything simpler.   That's how
site locals came about of course.

kre

---

From: Pekka Savola <[email-masked]>
Date: Wed, 16 Apr 2003 13:47:36 +0300 (EEST)

Robert, all,

Please note that the discussion was about "disconnected" case -- and for
that only.  Ensuring stable internal connectivity etc. is a different 
beast altogether.  What I tried to do is to scope issues in the case that 
site *is* actually disconnected -- and a special single-subnet case of 
that in particular.

Hijacking prefixes for stable internal connectivity while being connected 
to the Internet would be undoubtely a very bad practice :-).

That said, I'll try to answer the few points here and move discussion on 
other topics to other threads (to make it easier to other people to keep 
up).

> uses.   So, even assuming it is trivially easy, they won't change them.

Assume that the system is is quite simple, and changes could be done by 
knowledgeable person in less than 10 minutes.

Assume that the system would get a stable global prefix from the ISP.

Why would it want to keep its invented prefix?  Keeping it would actually 
hurt them too as it would be used in the source address selection and 
about a half of their packets would get return routed to /dev/null or some 
other site.  They'd certainly want to renumber.
 
> no bearing at all on the addressing I am using on my internal net.

This is outside of the scope of the original topic -- see a separate 
thread for thoughts on why ISP's change prefixes/addresses.

> No.   That's one scenario.

That was the specific scenario here (I think).  I didn't claim to analyze 
all the SL scenarios.

> Another is a link which is normally connected,

In this particular case, I wouldn't be worried about this at all, but
that's just me.
 
> of ways that none of us can imagine right now.

I agree that we can't force a model on people -- but then again, we *can* 
try to look at which models people have, and try to design solutions for 
that.

Looking at the problem of *disconnected* dentist's office (as far as I 
understood it) would be on such approach.
 
>   | is important of course, but was not the point here. 

Answered in different thread.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 23 Apr 2003 12:41:46 +0300 (EEST)

Sorry for the late answer, holidays..

> worse than anything we have today.

I agree that this is a potential problem -- the pieces don't fit together,
or are too different in such way that they increase the complexity
enermously.  However, I believe it might be possible to avoid this rathole 
as long as we remember it does exists.

> Why would it want to change?

Because due to those assumptions, changing would be relatively easy, and 
more importantly, it would make the hosts function better -- because the 
invented prefix is not special from any others in any way -- see below.
 
> will pick whatever 2000::/3 address my ISP has supplied me just now.

You assume that one picks the invented prefixes from "different enough" 
range.

Even still, this approach would seem to require more analysis.  Remember
that there are other rules that override the longest matching rule, e.g. 
prefer home/care-of addresses, and that for example "prefer matching 
label" would pick 8123:4567::/32 to a destination in 2001::/16 if the site 
would only have 6to4 addresses for IPv6 connectivity; destination address 
selection is likely to have similar issues.
 
> my internal connections break.

Not really (this can be both a good and a bad thing), it seems.
 
> that what is going on with that address is known by everyone.

fec0::/10 has also the "scope" element which is a much earlier tie-breaker 
in the address selection.  But this has its own problems too (the rules 
are not sufficient to prevent all the cases).

[another point moved to a separate thread]