Alan E. Beard wrote: > 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-/
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) > 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. 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: > > 1) Should we ask for something akin to the steps proposed below? 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?) > > 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. 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. > > OK, let the gates down - I'm eager for comments. 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 -------------------------------------------------------------------- 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 PROTECTED] --------------------------------------------------------------------
