Subject: RE: Fourth alternative [was Re: Moving forward ....]

From: <[email-masked]>
Date: Wed, 6 Aug 2003 13:58:02 -0700

Umm, the draft has *two* authors - not one. The requirements
and scenarios in the document are showing a *real need*
independent of whether link-local, site-local, limited-range,
global, provider-independent, etc etc. provide the best solution.
If you think the document has a scoping issue (no pun intended),
then let's discuss that with a measured tone.

Thanks,

Fred Templin
[email-masked]

> -----Original Message-----
> From: ext Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, August 06, 2003 12:47 PM
> To: Tony Hain
> Cc: 'Michael Thomas'; 'Brian E Carpenter'; [email-masked]
> Subject: RE: Fourth alternative [was Re: Moving forward ....]
> 
> 
> Tony Hain writes:
>  > Michael Thomas wrote:
>  > > The problem is that this draft proceedes from the
>  > > premise that the answer is consing up limited
>  > > range addresses. 
>  > 
>  > It is not intended to. It is trying to point out the 
> requirements that
>  > network managers have. It uses examples where they have 
> found limited range
>  > addresses meet the need to explain it for those who don't 
> believe their
>  > requirements are real. 
> 
> Tony, quit patronizing me and everybody else. I've
> not seen one person here who is insensitive to the
> actual needs of network managers. What I've seen
> is differing opinions of how to weigh the
> conflicts and most especially what the long term
> implications are of any particular approach. Your
> trying to frame these conversations as a one-man
> crusade against the IETF ivory-tower is lame and
> insulting.
> 
> Your draft is not helpful because it starts out
> with a conclusion and works back from there, much
> like yellowcake and WMD. The bias is in the title
> of the draft, for gawd sake. What we really need
> is something that lays out all of the requirements
> -- and local scope is not a requirement, it's a
> solution -- and tries to analyze the problem space
> without bias to a particular solution; laying out
> the good, bad and the ugly for each possible
> approach.
> 
>  > 
>  > > That's incorrect and not
>  > > helpful. We need to start by determining what the
>  > > *requirements* are, 
>  > 
>  > That is the point of the draft.
> 
> It fails. See above.
> 
>  >  Unfortunately some on this list want to
>  > argue that some requirements are not real, rather than 
> accept that different
>  > situations create different requirements. Given that not 
> everyone has
>  > expierenced every situation, the draft needs to provide 
> enough context
>  > around a requirement so that others can see the issue.
> 
> And now your patronizing the group again. Stop it.
>  
>  > > and only then outline what the
>  > > range of solutions are, and what their problems
>  > > and possible consequences are. Until we can get an
>  > > consensus on what we need to do, and what the
>  > > engineering tradeoffs are, we will never come to
>  > > closure.
>  > 
>  > Yes and no. There is no way to achieve a single optimal 
> solution for the
>  > diverse set of requirements, so we know the outcome will 
> be a compromise.
>  > Bob's draft (as did the others to randomize SL) meets the 
> requirements in
>  > the current draft.  
> 
> You mean the requirements of "do no harm wrt NAT
> and DFZ route pollution?" Oh, golly, I guess I
> didn't find those in the draft. Both of these
> requirement are downsides of limited scope
> addresses approach, btw.
> 
>  > > That in a nutshell is why I have a problem with
>  > > the religiosity on both sides of this argument.
>  > 
>  > My religion is that the deploying network manger is right, 
> no matter what
>  > the IETF decides. If the IETF decides to provide tools to 
> make deployment
>  > easy, that will be the path of least resistance. If not, 
> the network manager
>  > will demand ad-hoc tools to get the job done.
> 
> Aside from the preposterous notion that you're the
> torch bearer of the poor under represented network
> manager (::snort::), this isn't helpful because
> what we need here is to balance out the
> conflicting requirements both in whose work load
> is affected, as well as the general architecture
> of the net. The network manager is *one* voice
> that needs to be considered, not the *only* voice.
> 
> 	   Mike
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
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: Michael Thomas <[email-masked]>
Date: Wed, 6 Aug 2003 14:38:53 -0700 (PDT)

> then let's discuss that with a measured tone.

Yes, I think it has scoping issues. A name change,
for starters. It should first lay out requirements
of network operators, etc in terms of what they
need to accomplish not how they can accomplish it.
Take as a very large for example, address
stability. That's not the requirement, per
se. What they want is for topology tweaking to not
adversely affect running applications. However
protocols such as TCP are incapable of sustaining
sessions across address changes which is typically
needed when you want to move topology around.
That's the reason I say that "stability" is a
solution, not a requirement. Keeping addresses the
same is *a* way of keeping applications from
breaking, but not the only one. Mobile IP
obviously comes to mind, and there are other ways
we could envision like Fred's attempt at
operational renumbering.

Another example is your "well known prefix". I'd
think that the requirement is that certain
services and/or classes of devices need to be
isolated and/or invisible from the other parts of
the net. A well known prefix is a way to do that,
but it doesn't necessitate local scope and again
isn't the only way to wall stuff off. 

I really don't want to drag this into a meta
argument about the merits of various solutions,
but only to point out that the entire document is
structured in a way that the answer is foregone.
That's not what we need right now. We need
something that tries to be unbiased about the
ultimate compromises we're going to have to make
by saying what we want (requirements), what the
possible frameworks are for addressing the
requirements, and most especially what their
possible downsides are. We don't need boosterism
which tries to paper over the warts; all possible
solutions have problems, what we need is an honest
evaluation so that we can decide which path is the
least objectionable.

		Mike

---

From: Pekka Savola <[email-masked]>
Date: Thu, 7 Aug 2003 08:44:52 +0300 (EEST)

On Wed, 6 Aug 2003, Michael Thomas wrote:
[...]
> structured in a way that the answer is foregone.
[...]

Exactly.

Some others have also voiced concerns on this.  For example, Rob Austein 
made a similar comment at the Vienna meeting (I was already walking to the 
queue but he got there first :-).  At least I interpreted it like that.

-- 
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: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Aug 2003 08:51:59 +0200

Michael,

Sorry, but I think you are dead wrong, and you are moving us backward
and risking another year or two of wasted time.

There is nothing new in this whole argument. As I pointed out
in the IAB architecture session in Vienna, these issues have been
around for 6 years at least. We know what we can do with today's
routing mechanisms, today's renumbering mechanisms, and today's
security mechanisms, and that leads *directly* to the requirements
in the Hain/Templin draft, and IMHO *directly* to the solution in
the Hinden/Haberman draft.

I think we are way past the point in history where it is fruitful to
make the sort of free-space wish-the-world-was-different analysis
you are advocating. Hinden/Haberman leads to simple, straightforward
changes to shipping code and that's all we can afford now.

   Brian

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Leif Johansson <[email-masked]>
Date: Thu, 07 Aug 2003 10:18:25 +0200

Brian E Carpenter wrote:

<snip>

>the Hinden/Haberman draft.
Could you give a reference to some text which describes this reasoning in
more detail? I confess that I don't see the connections as clearly as 
you do.

To me Michael has presented some pretty good points and even if you are
right about the logical inevitability of the Hain/Templin draft it could imo
benefit from a bit more stringency.

       Cheers Leif

---

From: Michael Thomas <[email-masked]>
Date: Thu, 7 Aug 2003 09:11:34 -0700 (PDT)

> the Hinden/Haberman draft.

Which leads *directly* to NAT's at "local"
boundaries and /48's in the DFZ.

And Fred's draft really shows how little we know
about renumbering in the real world.

 > changes to shipping code and that's all we can afford now.

I'm having a very difficult time reconciling what
you're saying here with your "Let's abolish" post.
It's almost like you're saying we should do
nothing at all. While nothing is often better than
a bad something, in this case there's shipping
product to fill the vacuum: NAT's. And they are
well understood given their v4 deployment. Is that
what you're ceding?

	       Mike

---

From: Alain Durand <[email-masked]>
Date: Thu, 07 Aug 2003 10:39:08 -0700

Brian E Carpenter wrote:

>Hinden/Haberman leads to simple, straightforward
If apps could have dealt with those addresses the same way that they 
deal with
regular global unicast address, this would be true.
I'm affraid you're overlooking the impact on address selection here.

    - Alain.

---

From: Fred Templin <[email-masked]>
Date: Thu, 07 Aug 2003 10:57:37 -0700

Mike,

Let me see if I can understand your concerns better. It seems to me
that your main objection to the hain/templin draft is that you see it
as implying a particular solution genre, that being a limited range
addressing scheme to replace site-locals. If this is what you find
objectionable, then may I assume you are of the opinion that site
locals don't *need* to be replaced? If so, then it seems you would
favor an IPv6 addressing architecture that contains only link-local
and global unicast addresses, i.e., nothing in between?

The hain/templin draft discusses requirements for sites that frequently
change provider points of attachment, sites that are disconnected or
intermittently-connected to providers, sites that merge with other sites,
etc. In these cases, we require local application stability independent of
any provider-assigned addressing. This requirement is not satisfied by
link-locals for medium/large sites that comprise multiple links. Thus,
all we have left are globals and the only way the "active" sites I described
above could use these  would be if the global prefixes could be obtained
independent of any provider. Fine; so this just means that the sites would
get their own prefixes and tell providers which prefixes to advertise
instead of the other way around - right?

This would all be fine were it not for the fact that it would lead to
immediate global routing table explosion on the order of the number
of sites that procure their own prefixes which could be quite large.
I'm willing to suspend disbelief and say that sometime down the
road we might have a solution for scalable global routing, but in
what timeframe can we expect to see something like that deployed?
1yr? 5yrs? 10yrs? longer?

Scalable global routing in a flat addressing space certainly seems
like a utopian scenario if it can be achieved. But, if the deployment
timeframe is looking like mid/long term, then we still need some
sort of replacement for site-locals in the near term - right?

Thanks -  Fred
[email-masked]

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 7 Aug 2003 12:06:26 -0700

> I'm affraid you're overlooking the impact on address selection here.

Back to the flat earth concept ... 
Insisting on a single address per interface is the only way to avoid address
selection. Until we have a globally routed PI space we know there will be
multiple PA addresses to deal with, and in any case we know there will be
routing filters. Therefore there will be address selection with all the
potential for delays, so app developers simply have to get over it.
Complaining about address selection will not make routing filters go away,
because filtering is not something the IETF gets to decide.

There is a requirement for local application stability no matter what is
happening with the set of ISP interconnects. Unless applications have an
affinity for a limited range prefix, they will be susceptible to disruption
from external events. These external events would normally have absolutely
nothing to do with the operation of the local app, but if the external
interconnect is the only source of the address prefix these internal-only
apps will fail. This failure mode from prefix instability is absolutely
unnecessary and unacceptable. 

There is also a requirement to provide mechanisms that are simple for the
non-technical consumer to understand and deploy. This is the only way to
replace existing consumer friendly technologies like NAT. Telling the
consumer 'replacing the NAT is easy, all you have to do is configure the
filter for the port number ...' will ensure they continue using the
automated tool. Building automated tools requires simple deterministic
mechanisms that just work out of the box. This includes working in the case
where there is no external Internet connection, but may be a connection to
another out of the box network.

This whole discussion is about multihoming, which points out the failure of
the approach to move the multihoming discussion into a separate WG. Multi6
should be closed NOW, and that work should be folded back into the IPv6 WG
so there can be a comprehensive approach to the issues (this is independent
of the fact that the thread in an Ops WG is really about rearchitecting the
Internet). As we stand now, all discussions about multihoming are assumed to
be taking place over there, so we don't recognize the address selection
discussion as being the same thing. 

Tony

---

From: Michael Thomas <[email-masked]>
Date: Thu, 7 Aug 2003 12:52:34 -0700 (PDT)

> and global unicast addresses, i.e., nothing in between?

My inclination is that limited scope (excluding
link local) is extremely problematic, but that's
not really my larger point. The larger point is
that there are a set of requirements that are
driving people to use NAT's in ipv4 today, some of
which are well addressed by ipv6, some of which
are not as well addressed. And suspect that we all
know that ipv6 will get NAT's if those bread and
butter requirements cannot be met easily... NAT is
the devil they know right now, for better or
worse.

However, limited scope addresses are but *one* way
to deal with this set of requirements. What I
think has been getting short-shrift here is that
it seems to be a foregone conclusion amongst many
people -- especially those who were not in favor
of deprecation -- that the set of engineering
tradeoffs amongst the options is well known and
that local scoped addresses are the lesser of
evils. I find that far from clear, and to my
knowledge this working group has never formally
evaluated those options or even enumerated them
for that matter. I think it would be wise to take
on that work, so that we can make an informed
documented decision, and hopefully come to
consensus with our eyes wide open.

 > etc.

I think your draft would make a fine starting
point for the work I think needs done if it were
morphed into something that didn't proceed from a
solution and work backward as it seems to do now.

 > In these cases, we require local application stability independent of

It's all of these questions and tradeoffs etc,
which I think need to be *documented* and that we
need to get rough consensus about the *problem*
space itself. I don't believe after googlebytes of
email on site locals we even have consensus on
what problems must be solved in order to have a
deployable IPv6 without NAT's being a necessary
evil. Also: I think we are far away from actually
determining that the principle alternatives
(renumbering, PI) are dead letters, or that there
aren't other more creative ways of solving for the
problems/requirements.

Brian thinks this is a waste of time, I respectfully disagree.

	     Mike

---

From: Alain Durand <[email-masked]>
Date: Thu, 07 Aug 2003 17:32:44 -0700

>discussion as being the same thing. 
I agree that the issue discussed here is somehow related to multi-homing.
However, there is a fundamental difference.

You are proposing to encode local reachability information into
the address format and use address selection to prefer those addresses
in order to enforce local traffic to stay local.

The problem is that addresses are leaking and the fact that a node
is configured with a "local" address and it has a "local" address in its 
list
of destination addresses does not mean that both nodes are in the
same local "realm", i.e. there is a logical path to connect them.

So what we have here is a case where you are multihomed with
one side that is permanently unreachable from a large portion
of the universe.

    - Alain.

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 7 Aug 2003 17:59:39 -0700

> one side that is permanently unreachable from a large portion 

The only difference between this and the case for > 90% of the deployed end
systems today is the multihoming. Using PA addresses with filtering doesn't
change anything about the permanently unreachable state, it just makes it
impossible for anything to figure out which prefix is more likely to be
filtered. Applications don't have to try to figure it out, because not doing
so has exactly the same effect as filtered PA's. Those that choose to take
the hint can establish an affinity for the one more likely to that app.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Aug 2003 13:48:49 +0200

I share Tony's frustration with long hiatus in multi6, but it seems
to be unstuck at the moment. I also agree that it's hard to separate
the topics, but I see no practical advantage in repatriating the
multihoming issue into this WG, which already has a diverse agenda.

  Brian

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 8 Aug 2003 10:03:48 -0700

Brian E Carpenter wrote:
> I share Tony's frustration with long hiatus in multi6, but it 
> seems to be unstuck at the moment. I also agree that it's 
> hard to separate the topics, but I see no practical advantage 
> in repatriating the multihoming issue into this WG, which 
> already has a diverse agenda.

Yes it is unstuck, but I strongly suggest it be brought back into this WG
because (1) it is way outside the bounds of figuring out how to operate a
multihomed network, and into rearchitecting the system in ways that will
seriously undermine all assumptions about reachability and security, (2) is
completely off the radar of anyone that did not stick it out through the
dead time, & (3) is the root of the discussion here about the utility of
simultaneous use of addresses with different reachability characteristics. 

Tony

---

From: Alain Durand <[email-masked]>
Date: Fri, 08 Aug 2003 10:30:28 -0700

Tony,

I do not think it will work. Way too many efforts failed in the v6 wg
and it is time to focus, not create again a mega wg.

I have an alternate suggestion:
- recharter the ipv6 wg to focus on advancing the protocol elements.

- move the discussion on the operational requirements around
   the issues of address stability/locality/availability to v6Ops.
   after all, v6ops is the operational wg for IPv6!

- if multi6 and/or v6ops conclude that some fundamental changes
   need to happen wrt the address architecture, charter an ad-hoc wg to
   focus on this problem.

I think this course of action will enable us to make progress on this 
sensitive issue.

    - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Aug 2003 11:14:31 +0200

Leif,

I wish I could give you such a reference. In my mind it is a logical
path that started with RFC 1900 and RFC 2101, parts of RFC 2775 and
RFC 2956, parts of draft-irtf-nsrg-report-09.txt, and multiple discussions
on multi6, ipng and other lists over the years, and of course what we
have been told about operational practice.

Yes, it would be good to write it up.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Aug 2003 10:57:08 +0200

> I'm affraid you're overlooking the impact on address selection here.

Yes, certainly the default address selection rules would have to be
adapted. I don't see that as very tricky though. The tricky case is when
the default rules aren't suitable, but that isn't new.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Aug 2003 11:06:02 +0200

> boundaries and /48's in the DFZ.

As has been said by various people, all this is somewhat orthogonal to
whether NAT's appear. If we provide
a) unambiguous provider-independent prefixes
b) good mechanisms for running with these *in parallel* with routeable
provider prefixes
c) site multihoming
d) renumbering tools

we'll have done about all we can do, I believe, to make NAT unnecessary
and more painful than the alternative. But as usual, it's not the
IETF that decides what gets sold and used.

> you're saying here with your "Let's abolish" post.

Why? My point about the existing notion of scope is
that it is not useful, so we can drop it.

> well understood given their v4 deployment. Is that

No. I'm very frustrated at how slowly all this has developed,
but we should certainly get a) through d) above done.

     Brian

---

From: Michael Thomas <[email-masked]>
Date: Mon, 11 Aug 2003 10:19:45 -0700 (PDT)

> IETF that decides what gets sold and used.

It seems to me that in order to make "progress"
you seem to be saying that I have to make a leap
of faith that non-globally routable provider
independent addresses will not be abused. That is,
that people will not try to make the globally
routable by either NAT'ing them, or getting
providers to advertise the prefix. I'm sorry, but
nothing that goes on today gives me any reason to
make such a leap. 

 > that it is not useful, so we can drop it.

Well, I don't disagree. My larger point is the
desire for scoped addresses are a symptom of
requirements not being met (duh) but the heart of
the problem is that they are ignoring other
serious problems and/or requirements in their rush
to make a stopgap. Having all of the requirements
well know would be extremely helpful so that the
deficiencies can be evaluated instead of swept
under the rug.

 > but we should certainly get a) through d) above done.

What do you propose? The sticking point is and has
for a very long time been (a). You see it as
resolved, I don't. Why should I believe that this
will not result in NAT's, exponential route
growth, or most likely both? Also: you I believe
questioned the very premise of whether "local"
applications (eg, could use non-globally routable
addresses) were even particularly useful in real
life. If that's true, then what problem is (a)
solving? 

	   Mike

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 18 Aug 2003 17:49:07 +0200

(The reason for the late reply and all the late emails is that my 
laptop had a disk crash during my vacation, but I had a backup with 
mails I had replied to but not sent...)

	Tony,

On Thursday, August 7, 2003, at 09:06 PM, Tony Hain wrote:

> Internet).

I disagree with this. The multihoming problem is not a ipv6 problem 
alone.

> As we stand now, all discussions about multihoming are assumed to

This is not entirely true. I remember the chairs in Vienna actually 
asking what we should do with this issue and where it belongs. This was 
also brought up in the multi6 meeting. So the issue is recognized as 
being similar, if not the same.

Best regards,

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 18 Aug 2003 21:14:46 +0200

Agreed!

- kurtis -