> from realworld experience in providing IPv6 services at an ISP,
> and as a customer of that service:
>
> /48 PA assignments to the customer is sufficient.
> for roaming clients (like travelling laptops with PPP) there's a
> different requirement.
>
IMHO even a tr
> I think that those who believe v6 DHCP and auto-conf are sufficient to
> avoid the PI or local-autonomy requirement are deluding themselves,
> but one cannot prove such propositions until it is too late to prevent
> the undesired outcome.
>
> Counter-arguments?
from realworld experie
> IN ORDER TO AVOID v6 NAT: Network administrators of any home or
> enterprise network need to have, at essentially zero cost, "ownership"
> or control over SOME NUMBER of bits of the v6 address space,
> sufficient to uniquely address each host in their network, and such
> that a change in ISP
nice idea, but I'm fairly convinced that it's impractical. there are
just too many interfaces, many of them nonstandard and application
specific, that need to know about IP addresses.
maybe we could come up with a 90% solution, but that 10% is still a bear.
I'm back to thinking that we have to f
There seems to be consensus that trying to stop NAT in the v4 world is
futile. Good. So then we ask: "what will keep it from happening in
the v6 world?"
I postulate the following as one necessary, and perhaps sufficient,
condition:
IN ORDER TO AVOID v6 NAT: Network administrators of any home
Iljitsch,
On Aug 24, 2007, at 10:03 AM, Iljitsch van Beijnum wrote:
Regardless of the theatrics, this statement is still incorrect. As
I said in my previous message, you can't keep the old addresses
internally either so all of this buys you nothing.
I suspect the number of people who NAT in
On 24-aug-2007, at 18:44, 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.
Sigh. I forgot to be pedantic and use the IETF-mandated terminology.
If you ob
On 8/24/07, David Conrad <[EMAIL PROTECTED]> 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. It is a simple cost/benefit tradeoff, with the costs
> impacting software and protocol dev
Roger Jørgensen wrote:
On 8/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
No reason to attack him like you did and I specifically want to address
this because mailing lists have a much larger audience than their
participants. If such attacks are not answered it creates barriers for
new
On Aug 24, 2007, at 8:46 AM, Iljitsch van Beijnum wrote:
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.
Sigh. I forgot to be peda
On 8/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> No reason to attack him like you did and I specifically want to address
> this because mailing lists have a much larger audience than their
> participants. If such attacks are not answered it creates barriers for
> new blood to enter into
> 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
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 given
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 jus
> 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 pe
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 engi
> 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
> 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 d
> 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 w
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
ailto:[EMAIL PROTECTED]
> Sent: Thursday, 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 tec
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 often
>> 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
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 s
> 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).
itojun
__
> 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 from the namespace used
Larson, Matt wrote:
> On Thu, 23 Aug 2007, Keith Moore wrote:
>
>> basically DNS is not the sort of
>> thing you want to saddle every application in the Internet with,
>> [...]
>>
>
> It would seem that you are 20+ years too late. Just what color are
> the Frogstar fighters in your univers
> The DNS is a 1980's technology. We used hosts.txt prior to that.
yeah, that was a typo. (and I do remember using hosts.txt)
though somehow, 1980s technology doesn't sound a lot better.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailma
Sam Hartman wrote:
>> "Keith" == Keith Moore <[EMAIL PROTECTED]> writes:
>>
>
> Keith> Hallam-Baker, Phillip wrote:
> >> If we can meet the needs of 80% of Internet users with some
> >> form of shared access there will be more addresses left for the
> >> 20% wit
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?
Regards,
-drc
___
Ietf mailing list
Ietf@ietf.org
On Thu Aug 23 21:12:17 2007, Sam Hartman wrote:
> "Keith" == Keith Moore <[EMAIL PROTECTED]> writes:
Keith> Hallam-Baker, Phillip wrote:
>> If we can meet the needs of 80% of Internet users with some
>> form of shared access there will be more addresses left for
the
>> 20%
At 11:23 AM -0700 8/23/07, Hallam-Baker, Phillip wrote:
If we can meet the needs of 80% of Internet users with some form of
shared access there will be more addresses left for the 20% with
greater needs.
I suspect that the actual percentages are more like 95% and 5%.
My Internet use is certai
On Thu, 23 Aug 2007, Keith Moore wrote:
> basically DNS is not the sort of
> thing you want to saddle every application in the Internet with,
> [...]
It would seem that you are 20+ years too late. Just what color are
the Frogstar fighters in your universe, anyway? [1]
Matt
[1] http://en.wikiped
> "Keith" == Keith Moore <[EMAIL PROTECTED]> writes:
Keith> Hallam-Baker, Phillip wrote:
>> If we can meet the needs of 80% of Internet users with some
>> form of shared access there will be more addresses left for the
>> 20% with greater needs.
>>
Keith> with 2**128 p
Hallam-Baker, Phillip wrote:
> If we can meet the needs of 80% of Internet users with some form of shared
> access there will be more addresses left for the 20% with greater needs.
>
with 2**128 potential addresses, this is not only unnecessary, it's
harmful. there's far greater benefit to be
e Internet 2.0 box Was: IPv6 addresses really
> are scarce after all
>
> Hallam-Baker, Phillip wrote:
> > Why is Keith so desperately wedged on one particular means
> of achieving his objective?
> >
> because it's by far the simplest and most reliable means
I'm not sure we need to debate the subnet vs. bridging
question. Of course bridging will go a long way; yet I
don't think anyone on this thread wants to claim that
we should limit home networks to it.
The crux of the issue is the unpredictability of what
will happen with technology, a particular t
On 22-aug-2007, at 4:54, 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 fr
On 22-aug-2007, at 4:39, RJ Atkinson wrote:
In one's home network, which was and is the subject of this thread,
one ought not worry about backhoes taking out the cabling in the
attic. Since the uplink to the ISP would have a router in any
event, the part that might need to be redundant (i.e. th
>> no. the important point is that all users need to initially have enough
>> address space that they can attach not just multiple networks, but
>> multiple layers of networks, at that point. trying to define the
>> difference between the two types of end-users is silly. the reason that
>> IPv6
On 8/21/07, Keith Moore <[EMAIL PROTECTED]> wrote:
> Roger Jørgensen wrote:
> >
> > I am fully aware of that it will very likely be more than one subnet at some
> > point, that is why the last paragraph was included. Anyway, the important
> > point is that we probably should have two different type
> >>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 framing) have
> >consistently failed within the IEEE
>> 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 framing) have
>consistently failed within the IEEE 802.
> > "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 effectively
> K
On 21-aug-2007, at 18:39, Hallam-Baker, Phillip wrote:
It is entirely possible to make peer to peer applications work well
with NAT, it is entirely possible even to make a server application
work well with NAT.
It is entirely possible to make it so that you can breathe under
water. When t
Hallam-Baker, Phillip wrote:
> Why is Keith so desperately wedged on one particular means of achieving his
> objective?
>
because it's by far the simplest and most reliable means available.
> It is entirely possible to make peer to peer applications work well with NAT,
> it is entirely possibl
ing VOIP off the same box.
> -Original Message-
> From: Sam Hartman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 21, 2007 10:55 AM
> To: Keith Moore
> Cc: RJ Atkinson; ietf@ietf.org
> Subject: Re: IPv6 addresses really are scarce after all
>
> >&g
Sam Hartman wrote:
>> "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 "convenie
On 21-aug-2007, at 17:22, Suresh Krishnan wrote:
I am pretty sure the EUI-64 requirement has been dropped. If not I
can't see how the real world security practitioners are going to
implement it.
Stateless autoconf does not automatically imply EUI-64. There are
other stateless autoconf met
Hi Phil,
Hallam-Baker, Phillip wrote:
I am pretty sure the EUI-64 requirement has been dropped. If not I can't see
how the real world security practitioners are going to implement it.
Stateless autoconf does not automatically imply EUI-64. There are other
stateless autoconf methods that do n
> "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 effectively
Keith> thwarted
Hallam-Baker, Phillip wrote:
> Why do I need more bits to support more subnets?
>
you might not need them. but the ability for any consumer to buy a
router that will plug into any IPv6 network and automatically obtain a
subnet from its upstream router's /48 is very powerful. just because
you
> Fourth, lots of folks (me included) happen to find it convenient
> to use NAT between my site/house/office and my upstream provider.
do you also find it "convenient" that NAT has effectively thwarted the
deployment of huge numbers of new applications, significantly raised the
cost of deploying o
Roger Jørgensen wrote:
>
> I am fully aware of that it will very likely be more than one subnet at some
> point, that is why the last paragraph was included. Anyway, the important
> point is that we probably should have two different type of end-users, big
> and small.
no. the important point is
I am pretty sure the EUI-64 requirement has been dropped. If not I can't see
how the real world security practitioners are going to implement it.
The EUI-64 address reveals the hardware manufacturer and model of hardware that
I am using. There are no circumstances in which I am going to allow an
bject: RE: IPv6 addresses really are scarce after all
>
> > I know the reasons behind the /48 etc but it just going to cause us
> > trouble to keep it like that, we should divide the
> > /48 cateogry of users into two:
> > - people that can get the current /48 as long as
: Friday, August 17, 2007 8:54 PM
> To: Joel Jaeggli
> Cc: Keith Moore; ietf@ietf.org
> Subject: Re: IPv6 addresses really are scarce after all
>
> On Fri, 17 Aug 2007 17:01:39 -0700
> Joel Jaeggli <[EMAIL PROTECTED]> wrote:
>
> > Keith Moore 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 around
the limitations. If you create a loop in a bridged netw
caveat: i have not checked the entire thread yet, so it could be a
duplicate of someone's words.
> First, giving each end user a /64 means that the user can
> have up to 2^^64 devices at their site/home/office. That
2^64 interface ID is picked to reduce the possibility (o
I am quite startled by this thread, both in its emotion
and in the apparent oversight of multiple approaches
to the issue of having LOTS of connected user devices
at a house/site/office when an IPv6 /64 prefix has been
provided by one's upstream network provider.
First, giving each end user a /6
On 8/20/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > I know the reasons behind the /48 etc but it just going to
> > cause us trouble to keep it like that, we should divide the
> > /48 cateogry of users into two:
> > - people that can get the current /48 as long as they have
> > more than ON
> I know the reasons behind the /48 etc but it just going to
> cause us trouble to keep it like that, we should divide the
> /48 cateogry of users into two:
> - people that can get the current /48 as long as they have
> more than ONE subnet
> - people that only have ONE subnet, typical home-user
On 20-aug-2007, at 9:57, Roger Jørgensen wrote:
I would say this entire problem is related to the fact that a /48 is a
huge amount of IP addresses and most people have a hard time to
understand why everyone, even end-users (your grandmother or any other
non-technical users) should get this amoun
On Fri, 17 Aug 2007, [EMAIL PROTECTED] wrote:
> LIR's may assign blocks in the range of /48 to /64 to end sites.
> All assignments made by LIR's should meet a minimum HD-Ratio of .25.
>
> * /64 - Site needing only a single subnet.
> * /60 - Site with 2-3 subnets initially.
> * /56 - Site with 4-7
> From: <[EMAIL PROTECTED]>
> There is an overall architecture which IS DIFFERENT FROM IPv4 and which
> actually helps limit the growth of the global routing table.'
"The difference between theory and practise is even bigger in practise than
it is in theory." - S. Crocker
Noe
> Could you please site chapter and verse? Here's what I can find:
I quoted a formal proposal which has just been announced but which does
not yet have an official proposal number in the ARIN Policy Proposal
Archive. I believe this proposal met the deadline for discussion and
voting at the ARIN m
> In other words, a mesh of standard Ethernet bridges already
> allows you to partition traffic between the segments, without
> the need to do configuration of routers. (Yes, you do have to
> arrange the connectivity so that voice traffic doesn't have
> to go over the HD video network to get to
> "ARIN ... belives IPv6 addresses are ... resources that need
> to be [distributed] according to need."
>
> I guess I have to agree with this sentiment. If the ARIN
> community decides there is a better way to distribute IP
> addresses *OTHER THAN* need, I'd be really happy to hear what
> th
Tony Li wrote:
>>
>
>> When they do, they are violating the premises on which they received
>> their allocation. As such any ISP which is not willing to provide a /48*
>> to an end-user should get their IPv6 allocation revoked by the RIR.
>
>
> Could you please site chapter and verse? Here's wh
On Sat, 18 Aug 2007, Tony Li wrote:
> Sorry, ISPs charge based on providing a *service*. Yes, that
> includes bandwidth (and generally flat bandwidth, not usage) and also
Actually, bandwidth USAGE is frequently charged for in many parts of the
world. In the US, it is common for small businesse
> > yes, but it's unreasonable to expect a home user to not need to
> > subnet.
>
> You're kidding, right?
>
> You're actually expecting folks who couldn't set up VCR timers to
> configure _subnets_?
ISPs ship a DSL termination box with ethernet and wifi interface to
customer
When they do, they are violating the premises on which they received
their allocation. As such any ISP which is not willing to provide
a /48*
to an end-user should get their IPv6 allocation revoked by the RIR.
Could you please site chapter and verse? Here's what I can find:
http://www.
>> variable length addresses are a better idea than it appears at first
>> glance. they do bring certain difficulties with them, especially when
>> trying to do fiber-speed switching in hardware.
> Poppycock. Hardware for switching variable length addresses
> first showed up about 15 YEARS ago.
>
>> perhaps, but one might also reasonably expect 2^0 networks to be
>> insufficient.
>
>
> At the risk of repeating myself, I respectfully disagree. Given that you
> can reasonably build a flat subnet of 1000 hosts today, it does
> not seem like an unreasonable entry point. Mom & Pop 6-pack
> h
variable length addresses are a better idea than it appears at first
glance. they do bring certain difficulties with them, especially when
trying to do fiber-speed switching in hardware.
Poppycock. Hardware for switching variable length addresses
first showed up about 15 YEARS ago. This is
Keith,
perhaps, but one might also reasonably expect 2^0 networks to be
insufficient.
At the risk of repeating myself, I respectfully disagree. Given that
you
can reasonably build a flat subnet of 1000 hosts today, it does
not seem like an unreasonable entry point. Mom & Pop 6-pack
have
I retract what I wrote in a previous message about DFZ routers
needing to look at 64 bits of the packet's destination address.
I misunderstood the text:
> LIR's may assign blocks in the range of /48 to /64 to end sites.
> All assignments made by LIR's should meet a minimum HD-Ratio of
> .25.
>
>
> The only way to do what you want is to effectively have a variable
> length address. While there were a few crazy advocates of this many
> years ago, they were shouted down.
variable length addresses are a better idea than it appears at first
glance. they do bring certain difficulties with the
>> The issue is that IPv6 is architected to give sufficient addresses to
>> end users, and by screwing with this ARIN is harming both deployability
>> of IPv6, manaegability of IPv6, and usability of IPv6 by applications.
>
>
> First, there was never an architectural goal to give end users
> 'suff
Jeroen...
So I guess Comcast shouldn't be allowed IPv6 then? They refuse to provide
home users a static IP unless they upgrade to their $100+ business plans
which is quite unreasonable for home use... It pisses me off but it's all
part of their TOS game in which they state that "Public servers are
Tony Li wrote:
[..]
> Most MSOs would VERY much like to
> sell you a service with a fraction of an IPv4 address today, but they
> really haven't
> figured out how they could do so technically. For v6, they will always
> sell a service
> with a minimal amount of address, regardless of ARIN policie
a clever router/switch could certainly do a lot without subnetting.
Indeed. If you Google around a bit for "MAC table size", I think that
you'll find it hard to find an advertised size less than 1K entries,
and that's
for a shrink-wrapped 8 port switch.
I'll believe that entry level boxe
Keith,
It seems likely that cable mso's similar will dole out /64's to
customers one at a time, ...
The issue is that IPv6 is architected to give sufficient addresses to
end users, and by screwing with this ARIN is harming both
deployability
of IPv6, manaegability of IPv6, and usability o
> Keith,
>
> On Aug 18, 2007, at 2:04 AM, Keith Moore wrote:
> > yes, but it's unreasonable to expect a home user to not need to
> > subnet.
>
> You're kidding, right?
>
> You're actually expecting folks who couldn't set up VCR timers to
> configure _subnets_?
>
> Regards,
> -drc
On Sat, 18 Aug 2007, Terry Gray wrote:
> On Sat, 18 Aug 2007, Keith Moore wrote:
>
> > one of the areas in which I think the IPv4 design failed is that it
> > didn't really follow the catenet model. it was not possible to extend
> > the network from any point. and this is part of what led to N
On Sat, 18 Aug 2007, Keith Moore wrote:
> one of the areas in which I think the IPv4 design failed is that it
> didn't really follow the catenet model. it was not possible to extend
> the network from any point. and this is part of what led to NATs,
> because there really was a need to be able
>> yes, but it's unreasonable to expect a home user to not need to
>> subnet. particularly when there are so many different media
>> competing for the home network spaceit would be reasonable to
>> have a subnet for each medium.
>>
> I originally agreed with you on that. However, given m
>> yes, but it's unreasonable to expect a home user to not need to subnet.
>
> You're kidding, right?
>
> You're actually expecting folks who couldn't set up VCR timers to
> configure _subnets_?
no, I'm expecting subnets to be automatically configured by the border
router. when the prefix assig
Keith,
On Aug 18, 2007, at 2:04 AM, Keith Moore wrote:
yes, but it's unreasonable to expect a home user to not need to
subnet.
You're kidding, right?
You're actually expecting folks who couldn't set up VCR timers to
configure _subnets_?
Regards,
-drc
___
> From: Joel Jaeggli <[EMAIL PROTECTED]>
> Well lot's of people still think things like "why would home users ever
> subnet" ...
> At some point you stop wanting to have all those devices on the same
> network if for no other reason than to keep your multicast HD video
> st
On Sat, 18 Aug 2007 05:04:54 -0400
Keith Moore <[EMAIL PROTECTED]> wrote:
>
> >> I'm not sure what your point is -- I took Keith's comment to mean
> >> that home NATs with v6 were completely unacceptable.
> >
> >
> > /64's do NOT imply that there's NAT functionality involved, just
> > that there'
>> I'm not sure what your point is -- I took Keith's comment to mean that
>> home NATs with v6 were completely unacceptable.
>
>
> /64's do NOT imply that there's NAT functionality involved, just that
> there's
> a single subnet, yes?
yes, but it's unreasonable to expect a home user to not need to
Tony Li wrote:
>
> On Aug 17, 2007, at 4:05 PM, Keith Moore wrote:
>
>>
>>> It seems likely that cable mso's similar will dole out /64's to
>>> customers one at a time, I suppose that's acceptable if not necessarily
>>> desirable and will probably still result in the use of nat
>>> mechanisms in
>>
> It seems that someone in ARIN land believes that IPv6 addresses are
> scarce resources that need to be carefully dribbled out to customers
> according to need. The following proposal has just been formally made to
> change ARIN's allocation policy.
sorry, is there a URL so that i can che
I am concerned about DFZ routers needing to have their FIBs look at
48 bits of address for every packet sent to one of the new end-user
address blocks as allocated by ARIN, AfriNIC and now RIPE.
But this is up to 16 bits worse:
> * /64 - Site needing only a single subnet.
> * /60 - Site with 2-3
On Aug 17, 2007, at 5:54 PM, Steven M. Bellovin wrote:
I'm not sure what your point is -- I took Keith's comment to mean that
home NATs with v6 were completely unacceptable.
/64's do NOT imply that there's NAT functionality involved, just that
there's
a single subnet, yes?
Tony
On Fri, 17 Aug 2007 17:01:39 -0700
Joel Jaeggli <[EMAIL PROTECTED]> wrote:
> Keith Moore wrote:
> >> It seems likely that cable mso's similar will dole out /64's to
> >> customers one at a time, I suppose that's acceptable if not
> >> necessarily desirable and will probably still result in the use
On Aug 17, 2007, at 4:05 PM, Keith Moore wrote:
It seems likely that cable mso's similar will dole out /64's to
customers one at a time, I suppose that's acceptable if not
necessarily
desirable and will probably still result in the use of nat
mechanisms in
end systems.
that's COMPLETEL
Keith Moore wrote:
>> It seems likely that cable mso's similar will dole out /64's to
>> customers one at a time, I suppose that's acceptable if not necessarily
>> desirable and will probably still result in the use of nat mechanisms in
>> end systems.
>>
> that's COMPLETELY unacceptable.
Well
> It seems that someone in ARIN land believes that IPv6 addresses are
> scarce resources that need to be carefully dribbled out to customers
> according to need. The following proposal has just been formally made to
> change ARIN's allocation policy.
for the world peace, as long as it does
101 - 200 of 206 matches
Mail list logo
