Message
Subject: Re: Fourth alternative [was Re: Moving forward ]
Date: Wed, 20 Aug 2003 10:02:25 -0700
From: Fred Templin [EMAIL PROTECTED]
To: Erik Nordmark [EMAIL PROTECTED]
CC: Bob Hinden [EMAIL PROTECTED], Ralph Droms [EMAIL PROTECTED],
[EMAIL PROTECTED]
References: [EMAIL PROTECTED
On Tue, 19 Aug 2003 18:04:05 -0700
Tony Hain [EMAIL PROTECTED] wrote:
Erik Nordmark wrote:
...
FWIW, I think a multi6 solution with id/loc separation will
make the local addressing concerns go away.
Well a 'solution' might do that, but I don't see one happening in our
lifetimes. Any
Erik Nordmark wrote:
FWIW, I think a multi6 solution with id/loc separation will
make the local addressing concerns go away.
If it provides something that is almost as good as PI.
Tony Hain wrote:
Any separation will require a mapping infrastructure to
dynamically bind the values back
It's from my reading of the discussion (on the mailing list and in the
meetings) and the fact that the working group decided to accept
draft-hinden-ipv6-global-local-addr-02.txt as a working group document in
Vienna.
I didn't know there were such side effects associated with accepting
Erik:
I'm going to poke my nose into this thread in hope of alleviating some
possible misapprehension concerning interpretation of the original fourth
alternative text. Please see below for comments.
On Tue, 19 Aug 2003, Erik Nordmark wrote:
It's from my reading of the discussion (on the
Erik,
At 07:02 AM 8/19/2003, Erik Nordmark wrote:
I didn't know there were such side effects associated with accepting that
as a WG document.
My assumption was that it was a fine thing to work on possible replacements
and to understand the cost/benefit tradeoffs of such replacements.
But
Erik Nordmark wrote:
...
FWIW, I think a multi6 solution with id/loc separation will
make the local addressing concerns go away.
Well a 'solution' might do that, but I don't see one happening in our
lifetimes. Any separation will require a mapping infrastructure to
dynamically bind the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On onsdag, aug 6, 2003, at 06:40 Europe/Stockholm, Michel Py wrote:
That being said, the hard facts are that a) as of today 42% of my IPv6
BGP routing table is made of /48s, /64s and other crud and b) lots of
ISP will think twice before refusing
(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:
This whole discussion is about multihoming, which
On Thursday, August 7, 2003, at 11:37 PM, Michel Py wrote:
which points out the failure of the approach to move the
multihoming discussion into a separate WG. Multi6 should
be closed NOW.
As a matter of fact, by reading its charter it should have been
rechartered or shutdown in September 2001,
Alain Durand wrote:
Brian E Carpenter wrote:
Hinden/Haberman leads to simple, straightforward
changes to shipping code and that's all we can afford now.
If apps could have dealt with those addresses the same way that they
deal with
regular global unicast address, this would be true.
Alain Durand wrote:
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
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
Michael Thomas wrote:
Brian E Carpenter writes:
Eliot,
That seems to me to be orthogonal. I agree that it would be good to see
renumbering support (maybe it's a v6ops item??). But that doesn't destroy
the value of Bob's proposal.
I disagree. What we seem to be dancing around
Tony,
Tony Hain wrote:
Insisting on a single address per interface is the only
way to avoid address selection.
There are ample comments that a lot of enterprise managers will be
favorable to that concept.
This whole discussion is about multihoming
It has always been the sticking point.
Brian E Carpenter writes:
Michael Thomas wrote:
Which leads *directly* to NAT's at local
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)
Eliot,
Eliot Lear wrote:
I guess my concern is that ISPs end up routing the address
space in Bob's proposal and that we'll have another PI problem.
So while there's nothing wrong with Bob's proposal in theory
(indeed I prefer it vastly to the other SL approaches), if
customers believe they
August 05, 2003 12:02 PM Keith Moore wrote:
I concur. A real story for renumbering is probably the
biggest missing piece of the IPv6 puzzle, and we need to be
devoting our energies to solving this important problem
rather than to propagating past errors.
August 05, 2003 12:29 PM Keith
On Tue, Aug 05, 2003 at 05:29:37PM +0200, Brian E Carpenter wrote:
Eliot,
That seems to me to be orthogonal. I agree that it would be good to see
renumbering support (maybe it's a v6ops item??). But that doesn't destroy
the value of Bob's proposal.
Best practice and standards consideration
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
I disagree. What we seem to be dancing around with
here is an aversion to dealing with the actual
requirements of people who deploy networks.
What we seem to be dancing around with here is an aversion to dealing
with the actual requirements of people who write applications.
It is not
Brian E Carpenter writes:
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
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
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
Thirded, and agreed. IPv6 or V6Ops though?
On Tue, Aug 05, 2003 at 11:07:53AM -0700, Michael Thomas wrote:
Eliot Lear writes:
I'd like to put Fred on the spot (not having asked him) and propose that
his draft be adopted as a WG doc.
I'd like to second that. Fred's document if
Alain Durand wrote:
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.
This is a feature, not a bug.
Michel.
IETF IPng Working Group
Fred Templin writes:
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
Brian E Carpenter wrote:
Hinden/Haberman leads to simple, straightforward
changes to shipping code and that's all we can afford now.
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
Tim,
Michel Py wrote:
- If globally unique IPv6 address space is free, I am willing
to give these $2.5k/yr to my ISP to announce my /48.
Tim Chown wrote:
Well, the ISP announces it, but how far does it get?
It gets to you, where you filter it but it does get to you. You filter
it and
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,
Alain Durand wrote:
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.
The only difference between this and the case for 90% of the deployed end
systems today is the multihoming. Using PA addresses with
On Tue, Aug 05, 2003 at 09:40:52PM -0700, Michel Py wrote:
- If globally unique IPv6 address space is free, I am willing to give
these $2.5k/yr to my ISP to announce my /48.
Well, the ISP announces it, but how far does it get?
On the operator side, I do acknowledge that we have some of them
Brian E Carpenter writes:
Eliot,
That seems to me to be orthogonal. I agree that it would be good to see
renumbering support (maybe it's a v6ops item??). But that doesn't destroy
the value of Bob's proposal.
I disagree. What we seem to be dancing around with
here is an aversion to
Eliot Lear wrote:
I guess my concern is that ISPs end up routing the address
space in Bob's proposal and that we'll have another PI problem.
So while there's nothing wrong with Bob's proposal in theory
(indeed I prefer it vastly to the other SL approaches), if
customers believe they have
Michael Thomas wrote:
Brian E Carpenter writes:
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
[EMAIL PROTECTED] writes:
If you think the document has a scoping issue (no pun intended),
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
August 05, 2003 12:02 PM Keith Moore wrote:
I concur. A real story for renumbering is probably the
biggest missing piece of the IPv6 puzzle, and we need to be
devoting our energies to solving this important problem
rather than to propagating past errors.
August 05, 2003 12:29 PM Keith Moore
Brian E Carpenter wrote:
snip
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
On Wed, 6 Aug 2003, Michael Thomas wrote:
[...]
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.
[...]
Exactly.
Some others have also voiced concerns
Eliot / Bob,
Bob Hinden wrote:
Is this sufficient? Would it better to also include an
operational considerations or similar section? More text
on why this is important?
Eliot Lear wrote:
Venders speak the language of money,
So do operators and so do enterprises. Allow me to share the way
Eliot,
That seems to me to be orthogonal. I agree that it would be good to see
renumbering support (maybe it's a v6ops item??). But that doesn't destroy
the value of Bob's proposal.
Brian
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished
Bob Hinden wrote:
Is this sufficient? Would it better to also include an operational
considerations or similar section? More text on why this is important?
Bob,
Putting aside Michel's comments just for the moment, this would
seemingly be necessary, but I don't know if there is anything you
Bob,
I am sorry, but while it is a good attempt to come up with a happy
medium between SLs and global addresses, I disagree with the approach
that draft-hinden-ipv6-global-local-addr-02.txt takes. I would prefer
an approach that makes the stability of the IP address less important
rather
What this means to me is that first we need to promulgate something
along the lines of draft-baker-ipv6-renumber-procedure-00.txt. It
needs some expanding to further automate the process. The more we
automate the less pain the network manager will feel during a
renumbering event.
I
Interesting point.
Feel free to look up 192.102.91.0. It is being NAT'ed for a client of mine.
I've not convinced them yet to route it with a real firewall to their isp ;-(
--
Todd Fries .. [EMAIL PROTECTED]
Free Daemon Consulting, LLCLand: 405-748-4596
Christian,
It is possible to write sufficient restrictions and avoid both the drift
towards announcing /48 in the DMZ and using the unique local addresses in
a NATv6 configuration. The requirement is that the site local replacement
be special. We can for example request that backbone routers
46 matches
Mail list logo
