I'm glad to hear that RIRs can respond to users' concerns,
but that doesn't change the fact that they're second-guessing
an IETF decision and that other things in the IPv6
architecture are dependent on that design decision.
Given that the IETF has not released any documentation of the
Thus spake Tony Finch [EMAIL PROTECTED]
On Tue, 28 Aug 2007, Thomas Narten wrote:
As a data point, ARIN (in the last year) adopted a IPv6 PI for
end sites doing multihoming policy. Such end sites get a /48.
FWIW, technically the PI policy also covers folks that are single-homed,
though the
Thus spake Keith Moore [EMAIL PROTECTED]
The RIRs do not limit the discussion of operations experience
to a narrow few sources, rather the the discussion is open to all
and an array of perspectives are offered. The RIRs do not per
se discuss operations, the discussion is over policies that are
Thus spake John C Klensin [EMAIL PROTECTED]
Second, the notion that RIRs set addressing policy is one that
has not been in place forever. Indeed, it has evolved very
slowly and mostly by assertion by the RIRs that they have that
authority --assertions that, in other contexts, might look a lot
Thus spake Mark Andrews [EMAIL PROTECTED]
Keith == Keith Moore [EMAIL PROTECTED] writes:
Fourth, lots of folks (me included) happen to find it
convenient to use NAT between my site/house/office and my
upstream provider.
Keith do you also find it convenient that NAT has
The RIRs are definitely biased towards ISPs, because IP addressing
policy is a core business concern to ISPs but overhead to other
companies. The IETF has more vendors but still few end users.
However, there is adequate proof the RIRs can respond to end users'
concerns when anyone cares
Will all due respect, even if you assume a home with ten
occupants, a few hundred subnets based on functions, and
enough sensor-type devices to estimate several thousand of
them per occupant and a few thousand more per room, 2**64 is still a
_lot_ of addresses.
This is hyperbole. All
One of the things that I find myself wondering is whether home users
will need to establish VPNs to allow remote devices to access things in
their homes. And especially whether those remote devices will be
single devices or whether they will be on remote subnets. This would
imply a need for more
On 31-aug-2007, at 17:31, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
I still have not seen
any clear indication that there is a negative technical impact of
assigning a /56 per home.
Then you haven't been paying attention, I've been saying /56 is the
wrong size for some time now.
To
maybe I'm misled but I've never thought of the registries as bodies
whose purpose was to collect operational experience.
but yes, I'd very much like for IETF to have more input from those
involved in operation, as well as having more input from more
applications developers, as well as
no demonstration has been made that what IETF provided is not
operationally feasible. also, I suggest that the RIRs are only
considering operations from a narrow point-of-view.
Besides the lack of widespread operational adoption, no, no one has
proven it can't work. If it was
Jun-ichiro itojun Hagino wrote:
i repeat: voice your opinions AFTER you start using IPv6 daily.
i'm tired of this guessing games by people in ivory tower.
It's a perfect explanation of poor quality of IPv6 developed by
opinions voiced by those who never used IPv6.
E.g., stateless
On Thu, Aug 30, 2007 at 02:03:47AM -0400, Keith Moore wrote:
maybe I'm misled but I've never thought of the registries as bodies
whose purpose was to collect operational experience.
but yes, I'd very much like for IETF to have more input from those
involved in operation, as well as
On Tue, 28 Aug 2007, Thomas Narten wrote:
As a data point, ARIN (in the last year) adopted a IPv6 PI for end sites
doing multihoming policy. Such end sites get a /48.
I thought that routes in the IPv6 DFZ were not supposed to be more
specific than /32.
Tony.
--
f.a.n.finch [EMAIL PROTECTED]
On 30-aug-2007, at 12:22, Tony Finch wrote:
As a data point, ARIN (in the last year) adopted a IPv6 PI for end
sites
doing multihoming policy. Such end sites get a /48.
I thought that routes in the IPv6 DFZ were not supposed to be more
specific than /32.
Actually nobody really knows how
I thought that routes in the IPv6 DFZ were not supposed to be more
specific than /32.
Yes, another of the great myths. That somehow all IPv6 addresses would
be PAs, only ISPs would have them, and everyone would route on the
default ISP allocations (/32). Great idea in theory (if all you care
In the IETF, you need rough consensus to make decisions. I'm not
entirely sure how this works in all the RIRs, but I think at least
for ARIN, there is some form of voting involved.
ARIN also has a consensus call/declaration. Voting (at meetings) is
recorded for the record and for data.
On 30-aug-2007, at 15:11, Thomas Narten wrote:
Case in point is provider independent address space for IPv6. For a
decade, this wasn't possible because the IETF was first studying, and
after a _lot_ of effort to get things rolling, working on, mechanisms
to provide multihoming benefits without
I told Ray that I would write up something and send it to ARIN. but I
don't see how that will solve the problem of getting more relevant input
to IETF. allocation sizes still need to be decided in IETF, not by
RIRs. if it's really necessary to give RIRs or ISPs more bits to play
with,
Thomas Narten wrote:
[..] There was overwhelming support for the PI to end sites proposal.
Anyone who was at the ARIN meeting would have to take away two
things: 1) some people were seriously worried about the long-term
impact the policy would have on routing table size, and
2) there was
1. This is NOT ARIN's decision to make, nor that of any of
the other RIRs, because the /48 decision is not independent
of many other design decisions in IPv6.
Show me the document where this is explained.
I'm not disagreeing with you, I am just saying Show me the document
because if you
A /48 per 'site' is good, especially in the case of
businesses, for home-usage though, most very likely a /56
will be more than enough. As such IMHO having 2 sizes, one
business, one homeuser, would not be a bad compromise,
otherwise the really large ISP's, eg the ones having multiple
[EMAIL PROTECTED] wrote:
1. This is NOT ARIN's decision to make, nor that of any of
the other RIRs, because the /48 decision is not independent
of many other design decisions in IPv6.
Show me the document where this is explained.
for the most part, we don't document the rationale
[EMAIL PROTECTED] wrote:
A /48 per 'site' is good, especially in the case of
businesses, for home-usage though, most very likely a /56
will be more than enough. As such IMHO having 2 sizes, one
business, one homeuser, would not be a bad compromise,
otherwise the really large ISP's, eg the
Keith Moore wrote:
snip
IMHO home network connection is a misnomer. I'd call it commodity
network connection. The size of the network that is assigned to a home
ends up being the size of a network that you can get off the shelf,
for a fixed price, with minimal support, and using commodity
--On Tuesday, 28 August, 2007 16:43 -0700 Joel Jaeggli
[EMAIL PROTECTED] wrote:
This is the key point. And as David well knew when he posted
his note, LIRs are not end sites and are treated _very_
differently. A /32 is the default minimum size an LIR gets.
For those not familiar with the
On 8/29/07, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote:
snip
I think that we will find that there are 2 sets of user. Most users will
never subnet at all and be entirely happy with a /64.
just ONE /64 will almost never be enough. The reason are quite simple,
almost all types of connection
Note, while I think it's useful to have an educational discussion
about IPv6 addressing policy on the IETF list, it's also a tad
frustrating how selective/partial context quoting leads the discussion
veering off in all kinds of random directions...
I'd encourage folk to read the entire IPv6
In this whole discussion, I find it hard to keep separate the
technical issues, about which the IETF should care a lot, from
the business model and issues, about which the IETF should be
agnostic. We may personally care a great deal about the business
issues, but we cannot speak as an
Bob Braden wrote:
In this whole discussion, I find it hard to keep separate the
technical issues, about which the IETF should care a lot, from
the business model and issues, about which the IETF should be
agnostic. We may personally care a great deal about the business
issues, but we cannot
: Wednesday, August 29, 2007 12:58 PM
To: Bob Braden
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org
Subject: Re: IPv6 RIR policy [was Re: IPv6 addresses really are scarce
after all]
Bob Braden wrote:
In this whole discussion, I find it hard to keep separate the
technical issues
Ray Plzak wrote:
If you think that way, then why don't you say so on the ARIN Public Policy
Mailing List where such a comment needs to be heard. Discussion about ARIN
policy on this list will not influence the policy process.
I think the message needs to come from IETF that this isn't
: Keith Moore [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 29, 2007 3:52 PM
To: Ray Plzak
Cc: Bob Braden; [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org
Subject: Re: IPv6 RIR policy [was Re: IPv6 addresses really are scarce
after all]
Ray Plzak wrote:
If you think that way, then why
again, the fundamental problem here is that the RIRs are trying to
second-guess IETF design decisions.
the RIRs are membership organizations, with members
consisting of the operational community. they have to
try and work with whatever the IETF gives them.. and
I'd encourage folk to read the entire IPv6 policy to get a
more complete picture.
And, for those of you worried about end users being given a
/64 (or worse), from a registry perspective, it is 100%
acceptable to give every end site a /56. That is what the
above wording means, and that
On Wed, Aug 29, 2007 at 04:36:51PM -0400, Keith Moore wrote:
again, the fundamental problem here is that the RIRs are trying to
second-guess IETF design decisions.
the RIRs are membership organizations, with members
consisting of the operational community. they have
At 4:36 PM -0400 8/29/07, Keith Moore wrote:
no demonstration has been made that what IETF provided is not
operationally feasible. also, I suggest that the RIRs are only
considering operations from a narrow point-of-view.
Besides the lack of widespread operational adoption, no, no one has
On 29-aug-2007, at 22:21, Bill Manning wrote:
the RIRs are membership organizations, with members
consisting of the operational community. they have to
try and work with whatever the IETF gives them.. and when
what the IETF provides is not operationaly feasable,
Keith,
On Aug 29, 2007, at 1:36 PM, Keith Moore wrote:
no demonstration has been made that what IETF provided is not
operationally feasible.
Given the stunningly successful deployment of IPv6 ten years after it
has been standardized, I can see how you would say this.
IPv6 is fascinating
At 11:37 PM +0200 8/29/07, Iljitsch van Beijnum wrote:
In the IETF, you need rough consensus to make decisions. I'm not entirely
sure how this works in all the RIRs, but I think at least for ARIN, there
is some form of voting involved.
Every point I was going to make in response to this has
perhaps, but if IETF has the problem that it's not willing to assert its
ownership over its own protocols, that problem is better addressed in
IETF than in ARIN.
very true. but throwing protocols over the wall and
ignoring operational input does tend to affect the
i repeat: voice your opinions AFTER you start using IPv6 daily.
i'm tired of this guessing games by people in ivory tower.
itojun
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
no demonstration has been made that what IETF provided is not
operationally feasible.
Given the stunningly successful deployment of IPv6 ten years after it
has been standardized, I can see how you would say this.
and somehow the RIRs are going to fix this by changing the default
address
On Wed, Aug 29, 2007 at 10:58:21PM -0400, Keith Moore wrote:
perhaps, but if IETF has the problem that it's not willing to assert its
ownership over its own protocols, that problem is better addressed in
IETF than in ARIN.
very true. but throwing protocols over the wall and
i repeat: voice your opinions AFTER you start using IPv6 daily.
i'm tired of this guessing games by people in ivory tower.
To: field was wrong. your was general you.
itojun
___
Ietf mailing list
Ietf@ietf.org
On 20 Aug 2007, at 14:35, Jun-ichiro itojun Hagino wrote:
that's true, but when link MTU is different, it gets very nasty.
IEEE 802 standards do not permit variation in the link MTU
for Ethernet. Attempts to persuade IEEE 802 to approve use
of jumbo-MTUs (e.g. 9180 bytes + Ethernet
On 21 Aug 2007, at 22:54, Jun-ichiro itojun Hagino wrote:
IEEE 802 standards do not permit variation in the link MTU
for Ethernet. Attempts to persuade IEEE 802 to approve use
of jumbo-MTUs (e.g. 9180 bytes + Ethernet framing) have
consistently failed within the IEEE 802.
ok, then
On 20 Aug 2007, at 15:25, Iljitsch van Beijnum wrote:
On 18-aug-2007, at 16:27, RJ Atkinson wrote:
Second, Ethernet bridging is a well understood technology
and it works just fine even with very large numbers of devices.
That's a meaningless statement. Yes, it works well if you work
I agree with Dean entirely.
On 8/27/07 4:02 PM, Dean Anderson [EMAIL PROTECTED] wrote:
On Mon, 27 Aug 2007, Stephen Sprunk wrote:
Basically, because some people are too dense to use IPsec or SSL for
traffic
they don't want observed, you want to greatly complicate the average home
:39 PM
To: Iljitsch van Beijnum
Cc: ietf@ietf.org
Subject: Re: IPv6 addresses really are scarce after all
On 20 Aug 2007, at 15:25, Iljitsch van Beijnum wrote:
On 18-aug-2007, at 16:27, RJ Atkinson wrote:
Second, Ethernet bridging is a well understood technology
and it works just fine even
Hi Bob.
RFC3177, where the /48 recommendation was made, used the H ratio
analysis to explain why a /48 was acceptable. However the IETF did
not make any recommendation to the RIRs that the H ratio (current
version is now called HD ratio) should be used by the RIRs in their
Hi John.
Let me suggest a slightly different perspective on this.
First, the decision as to how large to make the IPv6 address
space is, and was, an architectural decision. We could have
chosen a longer length, we could have chosen a shorter one, we
could even have made it variable length
What I do hear is that giving out /48 to everyone is simply
profligately wasteful. And unjustified. And repeats the early mistakes
of IPv4 where people didn't think about managing resources prudently.
The people at the RIRs might genuinely feel this way, but I suggest that
they're not
Agreed.
But I think there was a lot more discussion about this in the very
early days, when 128 bits was chosen, and when stateless address
autoconfiguration assumed that the Interface Identifier part of an
address was 48 bits, leaving 64+16 bits for routing.
Then, we made the decision to
We shouldn't be surprised that a one size fits all approach
(where home users get the same amount of space by default as an IBM or
Microsoft) doesn't seem to make a lot of sense to some people.
I think this is a wrong comparison. The intent is to give a /48 to a
site where a site is either
But the /48 boundary is not. We had a long discussion about
that in the IPv6 WG, and our specs were carefully cleansed to
make sure there were no real dependencies on such a boundary.
Think Randy Bush saying your reinventing IPv4 classful
addressing about a thousand times. :-)
It is a
Thomas,
On Tue, Aug 28, 2007 at 04:09:14PM -0400, Thomas Narten wrote:
We shouldn't be surprised that a one size fits all approach (where
home users get the same amount of space by default as an IBM or
Microsoft) doesn't seem to make a lot of sense to some people.
US 2001:49c0::/32
John C Klensin wrote:
--On Tuesday, 28 August, 2007 15:06 -0700 David Kessens
[EMAIL PROTECTED] wrote:
Thomas,
On Tue, Aug 28, 2007 at 04:09:14PM -0400, Thomas Narten wrote:
We shouldn't be surprised that a one size fits all approach
(where home users get the same amount of space by
Joel Jaeggli [EMAIL PROTECTED] writes:
John C Klensin wrote:
--On Tuesday, 28 August, 2007 15:06 -0700 David Kessens
[EMAIL PROTECTED] wrote:
Thomas,
On Tue, Aug 28, 2007 at 04:09:14PM -0400, Thomas Narten wrote:
We shouldn't be surprised that a one size fits all approach
Thomas,
On Tue, Aug 28, 2007 at 07:26:03PM -0400, Thomas Narten wrote:
This is the key point. And as David well knew when he posted his note,
LIRs are not end sites and are treated _very_ differently. A /32 is
the default minimum size an LIR gets.
What you are saying here is that there is
Thomas Narten wrote:
Joel Jaeggli [EMAIL PROTECTED] writes:
John C Klensin wrote:
--On Tuesday, 28 August, 2007 15:06 -0700 David Kessens
[EMAIL PROTECTED] wrote:
Thomas,
On Tue, Aug 28, 2007 at 04:09:14PM -0400, Thomas Narten wrote:
We shouldn't be surprised that a one size fits all
. And if people find they need more than one /64 they can always get more.
Its not like they have to be contiguous.
From: Thomas Narten [mailto:[EMAIL PROTECTED]
Sent: Tue 28/08/2007 4:13 PM
To: John C Klensin
Cc: ietf@ietf.org
Subject: Re: IPv6 addresses really are scarce
Hallam-Baker, Phillip writes:
I don't see how such an architectural limitation can be enforced.
There is no way that the IETF can prevent an ISP issuing IPv6
customers a /128 if they choose.
Not directly, but there's the indirect route: a) IETF designs IPv6
autoconfiguration. b) Linksys,
Arnt Gulbrandsen wrote:
Hallam-Baker, Phillip writes:
I don't see how such an architectural limitation can be enforced.
There is no way that the IETF can prevent an ISP issuing IPv6
customers a /128 if they choose.
Not directly, but there's the indirect route: a) IETF designs IPv6
, August 27, 2007 5:11 AM
To: ietf@ietf.org
Cc: [EMAIL PROTECTED]; John C Klensin; Hallam-Baker,
Phillip; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: IPv6 addresses really are scarce after all
Hallam-Baker, Phillip writes:
I don't see how such an architectural limitation can be enforced
Hallam-Baker, Phillip writes:
Looks to me like people are trying to use technology to effect their
political goals.
Guilty as charged, and proud of it.
My political goal is to make computers help people in their daily life,
and I believe that eliminating the class of users without the
From: Hallam-Baker, Phillip [EMAIL PROTECTED]
Perhaps you could define the term subnet?
IP subnet, or subnet in the more general networking
(outside-the-IP-community - the null set these days, I know) sense?
For the first, originally, back in the days of class A/B/C network numbers,
(2) The many examples you give seem to be to be associated
with different domains of authorization and privilege for
different groups of people and functions within the home. My
impression of the experience and literature in the field is
that almost every time someone tries to create
Thus spake [EMAIL PROTECTED]
In my experience Ethernet bridges and switches are not
designed with security as a goal. When they fail to transmit
all incoming frames on all interfaces, it is to prevent segment
overload or broadcast storms. There are many cases where
people have found ways,
If I assign 4M /48's of IPv6 (one to each cable modem on my
network), according to the HD-ratio I am justified to obtain
something around a /20 of IPv6 addresses. In other words, I am
justified in getting 268M /48's even though I am only
using 4M of
them.
I find the fact that RFC 3177 has not been revised to reflect the
reality of today is a bit disapointing.
reality of today seems like an odd concept when trying to
make or revisit design decisions that will need to serve us
for decades. I keep seeing people making the same mistake of
The definition of a small network is pretty much single
subnet. Yes, I understand very well that the average home of
the future will have a mixed wiring. Of course, my own home
does have Ethernet and Wi-Fi. In the not so distant future,
it will have several Wi-Fi networks operating on
--On Sunday, 26 August, 2007 12:41 +0100 [EMAIL PROTECTED]
wrote:
The definition of a small network is pretty much single
subnet. Yes, I understand very well that the average home of
the future will have a mixed wiring. Of course, my own home
does have Ethernet and Wi-Fi. In the not so
Christian Huitema writes:
The definition of a small network is pretty much single subnet. Yes,
I understand very well that the average home of the future will have
a mixed wiring. Of course, my own home does have Ethernet and Wi-Fi.
In the not so distant future, it will have several Wi-Fi
Assume we agree on the needed functionality. It is hard to
disagree and many of us have seen the need to isolate some
people and apparatus from others, and to assign different
capability to them, for many years.
People want security, and the threats that Michael mention are real:
children
subnets have proven to a useful tool in the past, and may prove so again
in the future, even if the reasons for future use are different than
those for past and present use. I don't see why we should constrain the
network architecture to deny use of this tool to ordinary users.
Keith
Assume we
From: John C Klensin [mailto:[EMAIL PROTECTED]
Examples:
(1) Unless it was changed when I wasn't looking, there is a
rule in the IPv6 architecture that says that one cannot
subnet on a prefix longer than a /64. That rule appears to
be someone hostile to efficient use of address
(1) Unless it was changed when I wasn't looking, there is a
rule in the IPv6 architecture that says that one cannot
subnet on a prefix longer than a /64. That rule appears to
be someone hostile to efficient use of address space at the
small network with subnets side of things. Has
addresses really are scarce after all
Thomas,
A few additions to your description of how we got to where we are now
email.
RFC3177, where the /48 recommendation was made, used the H ratio
analysis to explain why a /48 was acceptable. However the IETF did
not make any recommendation
[CCing this to ARIN PPML and RIPE address-policy, but Reply-To:
ietf@ietf.org, when replying, please pick just one list. Also, please
read Thomas' entire original message at http://www1.ietf.org/mail-
archive/web/ietf/current/msg47431.html ]
[You may want to skip ahead to my point about the
From an architecture point of view, I believe there are only two
interesting delegation lengths, /48 and /64. My rationale is that
there really are two kinds of networks: big and small.
The definition of a small network is pretty much single subnet. Yes, I
understand very well that the average
--On Friday, 24 August, 2007 17:34 -0400 Thomas Narten
[EMAIL PROTECTED] wrote:
Some background and history.
The IETF gave it's view on where the boundary for IPv6 blocks
to end sites should be (i.e., the /48 recommendation) in RFC
3177 back in the 2000-2001 time frame.
At that time,
/64 is too small for a home network. It might indeed turn out that it's
possible to bridge several different kinds of media on a single subnet,
but it's bad planning to assume that this will be the case and overly
constrain home users. In addition, part of the popularity of NAT has
resulted from
--On Saturday, 25 August, 2007 12:28 -0400 Keith Moore
[EMAIL PROTECTED] wrote:
/64 is too small for a home network. It might indeed turn out
that it's possible to bridge several different kinds of media
on a single subnet, but it's bad planning to assume that this
will be the case and
John C Klensin wrote:
--On Saturday, 25 August, 2007 12:28 -0400 Keith Moore
[EMAIL PROTECTED] wrote:
/64 is too small for a home network. It might indeed turn out
that it's possible to bridge several different kinds of media
on a single subnet, but it's bad planning to assume that this
--On Saturday, 25 August, 2007 13:08 -0400 Keith Moore
[EMAIL PROTECTED] wrote:
John C Klensin wrote:
--On Saturday, 25 August, 2007 12:28 -0400 Keith Moore
[EMAIL PROTECTED] wrote:
/64 is too small for a home network. It might indeed turn
out that it's possible to bridge several
John,
It seems like we are on the same page. I'm very concerned about the
potential of this change to snowball in to lots of other changes that
would be undesirable, or at least highly disruptive. The /48 choice is
only one of several interlocking choices that were carefully-crafted
Noel Chiappa wrote:
From: Keith Moore [EMAIL PROTECTED]
what we really need is a layer of indirection at the BGP level so that
sites can have stable addresses without having to NAT.
You mean, have a namespace for use by the path-selection algorithms, one
which is separate
what we really need is a layer of indirection at the BGP level so that
sites can have stable addresses without having to NAT.
we should rather drop stable address requirement by having session
layer protocol (something better than TCP).
having a session layer protocol
On Fri Aug 24 01:48:00 2007, David Conrad wrote:
I'll take ease in renumbering over application transparency for
any
large network.
I find this confusing as a concern - how often do you renumber?
How often do you want to change service providers?
Well, I have a pretty good one, so not
, August 23, 2007 9:10 PM
To: Stephen Kent
Cc: Hallam-Baker, Phillip; RJ Atkinson; Sam Hartman; ietf@ietf.org
Subject: Re: The Internet 2.0 box Was: IPv6 addresses really
are scarce after all
The DNS is a 1980's technology. We used hosts.txt prior to that.
yeah, that was a typo. (and I do
Keith Moore [EMAIL PROTECTED] writes:
DNS is the Achilles heel of the Internet. it's way too unreliable, too
hard to configure correctly, too often out-of-sync with the real world.
it's not extensible enough.
DNS is surely the worst global naming system ever invented, except for
all the
From: Keith Moore [EMAIL PROTECTED]
I think it can be done without changes to IPv6, since it doesn't affect
the packet format, and the only things that have to know about it are
routers and network management tools.
I'm not sure I follow you. Are you talking about what we've
I try to learn from past efforts - both negative and positive. You on the
other hand demand that we consider the 1983 design of the Internet as
sacrosanct, except of course when you are sneering at people for proposing
'1980s technology'.
Okay, fair enough. Actually the Internet
Railing against the shortcomings of the current DNS (or any current
technology, for that matter) does little to get us to a better system.
If you know of a better approach, what are you doing to make it a
reality?
The purpose of my argument was to dispel the notion that DNS should be
Keith Moore wrote:
[..]
I believe I understand how to replace DNS with a better protocol while
preserving the existing hierarchy and RRsets and DNSSEC, and allowing
graceful transition from the old to the new. However, I'm not sure that
I have enough understanding of DNS's failings to
Bickering about all this is fun
of course, but it doesn't help coming to a solution, especially as the
solution doesn't have a defined problem set and what it is supposed to
solve.
of course. but the purpose was not to bicker, but rather to do some
damage control - to try to discourage
Dave,
On Aug 24, 2007, at 1:32 AM, Dave Cridland wrote:
I'm honestly struggling to see what the issue is here. I certainly
agree that renumering is a pain, but I don't follow why renumbering
is so significantly painful that it's worth breaking the network
for. I'm not saying it isn't, I
On 24-aug-2007, at 17:28, David Conrad wrote:
If you obtain address space from a service provider and you decide
to change providers, you have (in most cases) two options: renumber
or deploy NAT.
Nonsense.
Assuming you're not going to take the address space with you (which
is not a
The IETF has a simple process for all of this: write a draft.
Not true.
The IETF also runs a large number of mailing lists for discussion of
things both general and specific. It is not necessary to start work by
writing a draft. One can also start work by discussing the problem area
on one or
1 - 100 of 199 matches
Mail list logo
