Mailing List Archive

1 2  View All
IPv6 Address Planning [ In reply to ]
On Tue, Aug 16, 2005 at 05:08:22PM +0200, Lars Erik Gullerud wrote:
>
> Or, if it turns out "everyone" is actually using longer prefixes, then the
> vendors will make sure to support it. They follow the money. And don't
> particularly care what the academics and other non-ops people who spend
> their time bickering in various IETF-WGs over pointless details says as
> long as their real-world customers pay.

I can't let that absurd comment pass. I'll wager there's more production
IPv6 deployment in academic networks than anywhere else. Certainly in
Europe.

--
Tim/::1
IPv6 Address Planning [ In reply to ]
I think there is more production in academic and research networks at the
moment. But what is does indeed come down to is what the big paying
customers will want and use.

-M

--
Michael Nicks
Office: +1-913-538-2066
Mobile: +1-913-378-6516


-----Original Message-----
From: ipv6-ops-bounces+nicksm=guruassist.com@lists.cluenet.de
[mailto:ipv6-ops-bounces+nicksm=guruassist.com@lists.cluenet.de] On Behalf
Of Tim Chown
Sent: Tuesday, August 16, 2005 11:13 AM
To: ipv6-ops@lists.cluenet.de
Subject: Re: IPv6 Address Planning

On Tue, Aug 16, 2005 at 05:08:22PM +0200, Lars Erik Gullerud wrote:
>
> Or, if it turns out "everyone" is actually using longer prefixes, then the

> vendors will make sure to support it. They follow the money. And don't
> particularly care what the academics and other non-ops people who spend
> their time bickering in various IETF-WGs over pointless details says as
> long as their real-world customers pay.

I can't let that absurd comment pass. I'll wager there's more production
IPv6 deployment in academic networks than anywhere else. Certainly in
Europe.

--
Tim/::1
IPv6 Address Planning [ In reply to ]
On 16-aug-2005, at 17:08, Lars Erik Gullerud wrote:

> Accepting that you'd need space for 128 reserved anycast addresses
> on a p-t-p link is not something I'm prepared to do, I prefer to
> remain unreasonable. :)

I don't think this will cause problems, but it's not impossible that
at some point a router vendor screws this up and uses one or more of
these anycast addresses even though the subnet isn't large enough for
it. I wouldn't worry about this with our collective favorite vendors
starting with C and J, because they both have reasonably mature IPv6
implementations and have many ISP customers, but you may want to make
sure this isn't an issue for a new IPv6 router implementation when
you evaluate one.

>> it don't juts work, the /128, /127, /126 is a good exampe of that,
>> due to
>> change a /127 isn't usable over night :}

> /127 still seem to work just fine on my gear, fwiw.

But only because your router vendor doesn't implement the standard (=
all zeros is all routers anycast address). Others do. /127 is a very
bad idea.

>> the only way you can be guaranatied it will work are to use /64,
>> or /112
>> as everyone claim is okay...

> Or, if it turns out "everyone" is actually using longer prefixes,
> then the vendors will make sure to support it.

Unless I missed something, IPv6 is supposed to be classless, so any
prefix length shorter than 127 bits should work just fine. So there
is really no issue here.

(However, RFC 3513 requires interface identifiers to be 64 bit for
all IPv6 space except ::/3 and stateless autoconfiguration only works
if the prefix advertised by routers + the interface identifier are
128 bits combined, so stateless autoconf only works on /64 prefixes.)
IPv6 Address Planning [ In reply to ]
On Tue, 16 Aug 2005, Tim Chown wrote:

> On Tue, Aug 16, 2005 at 05:08:22PM +0200, Lars Erik Gullerud wrote:
>>
>> Or, if it turns out "everyone" is actually using longer prefixes, then the
>> vendors will make sure to support it. They follow the money. And don't
>> particularly care what the academics and other non-ops people who spend
>> their time bickering in various IETF-WGs over pointless details says as
>> long as their real-world customers pay.
>
> I can't let that absurd comment pass. I'll wager there's more production
> IPv6 deployment in academic networks than anywhere else. Certainly in
> Europe.

That observation is quite likely correct, and my comment was not targeted
at academic networks nor the ops people who run them, so I am sorry if
anyone misinterpreted the meaning of my comment as you seem to have and
felt offended by it, which was not my intention. It was not a
comment upon IPv6 in particular and certainly not as regarding
operational use of it, but rather a generalized reflection on the "state
of affairs" in _various_ IETF workgroups (as I also stated), where one
sees that far too many proposals gets bogged down in meaningless
discussions over details who are probably not interesting for the
majority of network operators - academic or commercial. So instead the
vendors choose to implement whatever their customers demand (and are
willing to PAY for) rather than waiting for the appropriate forum
within the IETF to come to an agreement.

Which, again letting my disgruntlement shine through, seems to usually be
a process involving a few competing vendor representatives pushing their
particular (company-sponsored) agendas, some academics with no operational
background but with more or less well-researched theories on various
aspects of the internet, a handful of very stubborn individuals with
bright(?) ideas on how the Internet should be, and a shrinking minority of
not-yet-disillusioned clueful individuals desperatly trying to let sanity
prevail. Fortunately, there are a few exceptions to this, generally found
in the groups where the "bikeshed factor" is lower. :)

Now, while I'm sure some people will blatantly disagree to my very broad
generalizations on this topic also, that is a discussion that probably
belongs somewhere other than this particular list, so I suggest you flame
me appropriately off-list instead, or suggest a more suited venue for it
instead. :)

/leg
IPv6 Address Planning [ In reply to ]
Not really sure about that, early adopters probably, but today IPv6 is not
only for "early adopters", but in any case, that's irrelevant, as they also
pay for the cost of developing IPv6 products.

Remember also that academic networks, in most cases, use regular big
operational networks.

Regards,
Jordi




> De: Michael Nicks <mnicks@guruassist.com>
> Responder a: <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de>
> Fecha: Tue, 16 Aug 2005 11:22:16 -0500
> Para: 'Tim Chown' <tjc@ecs.soton.ac.uk>, <ipv6-ops@lists.cluenet.de>
> Asunto: RE: IPv6 Address Planning
>
> I think there is more production in academic and research networks at the
> moment. But what is does indeed come down to is what the big paying
> customers will want and use.
>
> -M
>
> --
> Michael Nicks
> Office: +1-913-538-2066
> Mobile: +1-913-378-6516
>
>
> -----Original Message-----
> From: ipv6-ops-bounces+nicksm=guruassist.com@lists.cluenet.de
> [mailto:ipv6-ops-bounces+nicksm=guruassist.com@lists.cluenet.de] On Behalf
> Of Tim Chown
> Sent: Tuesday, August 16, 2005 11:13 AM
> To: ipv6-ops@lists.cluenet.de
> Subject: Re: IPv6 Address Planning
>
> On Tue, Aug 16, 2005 at 05:08:22PM +0200, Lars Erik Gullerud wrote:
>>
>> Or, if it turns out "everyone" is actually using longer prefixes, then the
>
>> vendors will make sure to support it. They follow the money. And don't
>> particularly care what the academics and other non-ops people who spend
>> their time bickering in various IETF-WGs over pointless details says as
>> long as their real-world customers pay.
>
> I can't let that absurd comment pass. I'll wager there's more production
> IPv6 deployment in academic networks than anywhere else. Certainly in
> Europe.
>
> --
> Tim/::1
>
>
>




************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Information available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

1 2  View All