Subject: RE: Enforcing unreachability of site local addresses

From: "Michel Py" <[email-masked]>
Date: Fri, 14 Feb 2003 14:04:37 -0800

> Tony Hain wrote:
> We are at an impass.

Indeed.

> this puts the ADs in a bind, because they would have a hard
> time justifing that the IPv6 wg should be tasked with defining
> an operational plan that an Operations Area wg is already
> tasked to do.

Yep. Some will remember that in an attempt to shake things up, a year or
two ago I tried to bypass multi6 and sent my text to ngtrans. The result
was the addition of text in the ngtrans charter that specifically
labeled multihoming solutions as non-goals that would not be looked at
by the WG. We're deadlocked.

> It is exactly that business model where PI approaches like
> Michele's or mine work well. 

To set the record straight, Tony's drafts have been one of the major
sources inspiring GAPI in the early stages. One of the interim releases
of MHAP actually used Tony's scheme before GAPI was written.

> I have a document that describes the situation and need for PI:
> http://www.tndh.net/~tony/ietf/ipv6piaddressusage-04.txt

I never bothered writing something like this as Tony's text is also
valid for GAPI for the most part. Read it.

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: "Alan E. Beard" <[email-masked]>
Date: Sat, 15 Feb 2003 13:25:11 -0500 (EST)

Folks:

OK. In the past several days, I have:

read Tony's ipv6ipaddressusage-04 draft
read Michel's gapi-00 draft
reviewed the site-local use discussion in the IPv6 WG
read the Multi6 charter
read the Multi6 requirements draft
re-read RFC 2373 and RFC 2374
re-read the addr-arch-v3 draft
re-read the ipv6-prefix-delegation-requirement-00 draft
re-read the ipv6-ipaddressassign-06 draft
read Iljitch van Beijnum's multi6-isp-int-aggr-00 draft
read Michel's Multi Homing Aliasing Protocol draft

I went back and ploughed through my archive of ngtrans mail.

At one point I thought I had got myself into a configuration which
features a permanently recirculating digestive system.  8-/

There is much high-quality work in the documents and discussions cited
above. Each of the drafts proposes a solution to a specific problem or
elememt of a problem, or, in some cases, proposes tools to handle some of
the effects of the percieved problem; the proposals have substantial
technical merit, and all deserve full and careful consideration.

After working through the reading listed above, a disturbing notion began
niggling around in the back of my brain (what little there is of it). More
below.

> Indeed.
No wonder we're at an impasse:  we have a blind-men-and-the-elephant
problem here!

Each of the discussions and drafts cited above defines a problem, and, in
most cases, proposes a solution for that problem or a tool to help
constrain the problem space.  As I read the documents and discussion logs,
all the problems described converge on a common underlying root issue.
In effect, each group or author has siezed upon one aspect of the root
issue (one the trunk; another an ear, the third a leg; ...) and then
described a possible solution for that aspect of the issue.

I suggest that we might be able to make more progress if we directly
address the underlying issue.  This is not to sugggest that the problems
severally described in the citations above will automagically disappear
once the root issue is resolved; however, I think that most (probably all)
of the discrete problems will then become much easier to solve.

The common, underlying issue, as I see it, is:

The use of PA space in end-user networks has the effect of imposing upon
those networks functional burdens and restrictions in multiple areas which
the managers of commercial end-user networks may be unwilling to tolerate.

In consequence, we may need to reconsider our current address allocation
practice, which relies principally on the PA model, in light of current
user expectations, current state of the routing protocols and standards,
and anticipated developments in routing and switching code.

Given the present state of our technologies, any discussion of a change in
address allocation models will inevitably entail extensive consideration
of scalability and routing-table-size issues, along with aggregation and
related matters.

> by the WG. We're deadlocked.
I think we may be able to break the deadlock and, for lagniappe, get the
ADs out of their bind (provided they really are so constrained) by
proposing to deal directly with the root issue rather than continuing to
nibble away at the leaves.

As I read the charters and tasks lists, there are mutiple tasks extant
which treat some aspect of the PA functional restrictions and burdens on
end-user networks, but no task which coordinates activities across the
multiple working groups on the issues arising from PA in end-user
networks. Additionally, there is no task open which deals directly with
the user-community concerns over the functional burdens imposed on
end-user networks by forced use of PA.

> of MHAP actually used Tony's scheme before GAPI was written.
The drafts cited above present tools and practices which may very well be
a part of the solution set for the underlying issue, in adddition to
providing specific solutions in particular functional areas.

> valid for GAPI for the most part. Read it.
I have read Tony's draft, and it does contain a very good statement of
specific needs which are amenable to solution by use of PI.  This is very
fine work indeed.

Now, I intend to make a specific proposal on next steps below, and then
pose these questions:

1) Should we ask for something akin to the steps proposed below?

2) Is there another approach which will work at least as well, and, if so,
what is it?

3) Are we approaching this matter hind-end-foremost?

or

4) I am the functional equivalent of a skunk with his head stuck in a tin
can?  (Alternately expressed: is this proposal fundamentally wrong-headed,
and should we abandon it in favor or more productive discussions?)

Here is a starting point for discussion of next steps.  We may wish to:

1) Ask the IPv6 WG chairs and the Internet Area ADs to add to the IPv6
task list a work item which directs the WG to coordinate and support
extant activities in other WGs which deal with issues surrounding use of
PA and PI address spaces in, or at the boundaries of, end-user networks.
(Note: this language will need to be clarified. Suggestions welcome.)

This is incontestably within the working group charter, as indicated by
this charge in the charter statement:

- Serve as a review board and body of competence and coordination for IPv6
architectural issues that span multiple IETF working groups.

2) Ask the IPv6 WG chairs and the Internet Area ADs to add to the IPv6
task list a work item which directs the WG to review and, if needed,
recommend revisions to the current IPv6 unicast address allocation
practice in light of current user expectations, current state of the
routing protocols and standards, and anticipated developments in routing
and switching code.

Here again, this is incontestably within the scope of the WG charter, as
indicated by this charge in the charter statement:

- Provide technical input to the IAB, IANA and Internet Address Registries
with regard to IPv6 address allocation policies and procedures.

OK, let the gates down - I'm eager for comments.

Regards,

AEB

-- 
Alan E. Beard <[email-masked]>
AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809
863.815.2529

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 16 Feb 2003 21:05:58 +0100

> read Michel's Multi Homing Aliasing Protocol draft

Hey you forgot multihoming-longprefix-00.txt! :)

> architectural issues that span multiple IETF working groups.

This is not a IPv6 problem. It's a routing problem at best. If we 
continue to have the IPv6 groups to work on behalf on other groups we 
will not get far. I have no clear solution to this, but I strongly 
disagree to put this under the IPv6 WG.  This might belong in IDR, but 
I guess that would require to re-charter IDR.

I think that you to some extent are right in your observations. This is 
a problem that will impact the solution of a number of other problems, 
as these will impact a number of possible solutions to PI vs PA.

However, me (and I think a number of other people) are starting to 
think that everything discussed so far is just pointing to us trying to 
paint IPv6 in nice colors to try and hide it's ugly shapes. Maybe the 
problem is somewhere else and a lot deeper. This seems to be a lot more 
politically sensitive to bring up though.

Best regards,

- kurtis -

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 17 Feb 2003 09:56:08 -0800

Alan E. Beard wrote:
> At one point I thought I had got myself into a configuration 
> which features a permanently recirculating digestive system.  8-/

And you are still coherent enough to send mail?!?! 

> ...
> > > We are at an impass.
> >
> > Indeed.
> >
> >
> No wonder we're at an impasse:  we have a 
> blind-men-and-the-elephant problem here!
> 
> Each of the discussions and drafts cited above defines a 
> problem, and, in most cases, proposes a solution for that 
> problem or a tool to help constrain the problem space.  As I 
> read the documents and discussion logs, all the problems 
> described converge on a common underlying root issue. In 
> effect, each group or author has siezed upon one aspect of 
> the root issue (one the trunk; another an ear, the third a 
> leg; ...) and then described a possible solution for that 
> aspect of the issue.

Well, I would describe it more as trying to find the balance point
between a divergent set of contradictory requirements. 

> 
> I suggest that we might be able to make more progress if we 
> directly address the underlying issue.  This is not to 
> sugggest that the problems severally described in the 
> citations above will automagically disappear once the root 
> issue is resolved; however, I think that most (probably all) 
> The use of PA space in end-user networks has the effect of 
> imposing upon those networks functional burdens and 
> restrictions in multiple areas which the managers of 
> commercial end-user networks may be unwilling to tolerate.

While this is a problem statement that has been missing from the
historical discussions, it would fit more in the elephant metaphor
bucket. The fundamental problem is that decisions get made without all
interested parties having a voice.

> ...
> Additionally, there is no task open which deals directly with 
> the user-community concerns over the functional burdens 
> imposed on end-user networks by forced use of PA.

Well, arguably the multi6 wg is supposed to be considering the input of
the multihoming sites. Unfortunately the route scaling camp continues to
drown out that input with claims that we only know how to scale PA
unless we rearchitect the entire Internet with route scaling as its
primary focus.

> ...
> Now, I intend to make a specific proposal on next steps 
> below, and then pose these questions:
> 

Akin, yes. Directing where the work gets done, probably not. 

> 
> 2) Is there another approach which will work at least as 
> well, and, if so, what is it?

Maybe something as simple as an informational RFC written by edge
network managers. Such a document should state a set of requirements
that the architectural & operational working groups would need to meet.
Your mail in this thread provides a good starting point, and I am sure
we could find a few others with an edge perspective to participate. One
thing I would caution, in addition to stating that renumbering is not
tolerable, there should be some documentation of the reasoning. Having
forgotten about many of the unusual places people stick addresses, I had
convinced myself that most of the objection to renumbering hosts was the
painful process of doing it in IPv4. We worked hard to make renumbering
the host itself a non-issue, but overlooked all the obscure places
people stick explicit addresses. 

> 3) Are we approaching this matter hind-end-foremost?

No, but it probably feels that way.

> 
> or
> 
> 4) I am the functional equivalent of a skunk with his head 
> stuck in a tin can?  (Alternately expressed: is this proposal 
> fundamentally wrong-headed, and should we abandon it in favor 
> or more productive discussions?)
> 
> 1) Ask the IPv6 WG chairs and the Internet Area ADs to add to 
> the IPv6 task list a work item which directs the WG to 
> coordinate and support extant activities in other WGs which 
> deal with issues surrounding use of PA and PI address spaces 
> in, or at the boundaries of, end-user networks.
> This is incontestably within the working group charter, as 
> - Serve as a review board and body of competence and 
> coordination for IPv6 architectural issues that span multiple 
> IETF working groups.

Well I would agree, except the intent of multi6 was to address all of
the issues consistently within one focused working group. Reality is
another story.

> 
> 2) Ask the IPv6 WG chairs and the Internet Area ADs to add to 
> the IPv6 task list a work item which directs the WG to review 
> and, if needed, recommend revisions to the current IPv6 
> unicast address allocation practice in light of current user 
> expectations, current state of the routing protocols and 
> standards, and anticipated developments in routing and switching code.
> 
> Here again, this is incontestably within the scope of the WG 
> charter, as indicated by this charge in the charter statement:
> 
> - Provide technical input to the IAB, IANA and Internet 
> Address Registries with regard to IPv6 address allocation 
> policies and procedures.
> 

No objection to your desire to see progress, but maybe the simplest way
forward would be to have a few edge network managers write a simple RFC
that says, our requirements are X,Y,Z, and they are not being met by the
current state of the standards. Achieving the goal of address stability
requires either, SL+NAT using PA allocations, or PI. 

Tony