In message , Owen DeLong write
s:
>
> On Jun 15, 2011, at 9:39 AM, Leo Bicknell wrote:
>
> > In a message written on Wed, Jun 15, 2011 at 10:22:12AM -0500, Jima wrote:
> >> Oh, oops; you did touch upon this. You might want to let the people
> >> who've implemented RDNSS in software know that t
On Jun 15, 2011, at 10:21 AM, valdis.kletni...@vt.edu wrote:
> On Wed, 15 Jun 2011 19:04:44 +0200, sth...@nethelp.no said:
>
>> How big is huge? To some degree it depends on how broadcast "chatty"
>> the protocols used are - but there's also the matter of having a
>> size which makes it possible
On Jun 14, 2011, at 10:56 PM, Iljitsch van Beijnum wrote:
> On 15 jun 2011, at 7:33, Owen DeLong wrote:
>
>> Bottom line, I expect it's easier to get cooperation from OS vendors and
>> BIOS vendors to make changes
>> because experience has shown that they are more willing to do so than
>> vert
On Jun 14, 2011, at 9:43 PM, Joel Jaeggli wrote:
>
> On Jun 13, 2011, at 5:41 PM, Owen DeLong wrote:
>
>>
>> On Jun 12, 2011, at 11:12 AM, Iljitsch van Beijnum wrote:
>>
>>> On 12 jun 2011, at 15:45, Leo Bicknell wrote:
>>>
> Like I said before, that would pollute the network with many m
> Are you not using managed switches?
Certainly.
> It takes me about 1 second to find exactly which device and which port
> a device is connected to. Once you know that; you have a pretty nice
> collection of statistics and log messages that usually tell you
> exactly what is wrong.
Here is whe
Are you not using managed switches?
It takes me about 1 second to find exactly which device and which port
a device is connected to. Once you know that; you have a pretty nice
collection of statistics and log messages that usually tell you
exactly what is wrong.
Or am I missing something?
On Th
> "Ethernet doesn't scale because of large amounts of broadcast traffic."
>
> We started to introduce multicast, and multicast-aware switches in
> IPv4; in IPv6 there is no broadcast traffic. We won't be able to
> scale networks up until we can turn off IPv4,
In other words, probably not for ano
On Jun 15, 2011, at 9:39 AM, Leo Bicknell wrote:
> In a message written on Wed, Jun 15, 2011 at 10:22:12AM -0500, Jima wrote:
>> Oh, oops; you did touch upon this. You might want to let the people
>> who've implemented RDNSS in software know that the IETF is working on
>> it. I'm sure that'll
On Jun 15, 2011, at 8:52 AM, Iljitsch van Beijnum wrote:
> On 15 jun 2011, at 16:52, Tony Finch wrote:
>
>> Ethernet is not designed for huge LANs. If you want that you need
>> to make significant changes - http://www.cl.cam.ac.uk/~mas90/MOOSE/
>
> Hm:
>
> "Our object is to design a communicat
The beauty of Ethernet is that it's simple. "Ethernet" has evolved
considerably, and continues to do so. It's not really fair to make
comments about it's sociability and talk about it as if it were still
in the state it was 20 years ago:
"Ethernet doesn't scale because of collisions and exponent
On Wed, 2011-06-15 at 17:52 +0200, Iljitsch van Beijnum wrote:
> "Our object is to design a communication system which can grow smoothly to
> accommodate several buildings full of personal computers and the facilities
> needed for their support."
>
> Ethernet: Distributed Packet Switching for Lo
On 06/15/2011 11:45 AM, Iljitsch van Beijnum wrote:
On 15 jun 2011, at 18:39, Leo Bicknell wrote:
Maybe I'm missing something, but the last update on this was RFC
5006 I think, which is marked as "experimental", and I thought the
IETF still had a working group discussing it.
You missed the up
On Wed, 15 Jun 2011 19:04:44 +0200, sth...@nethelp.no said:
> How big is huge? To some degree it depends on how broadcast "chatty"
> the protocols used are - but there's also the matter of having a
> size which makes it possible to troubleshoot. Personally I'd prefer
> an upper limit of a few hund
> > Ethernet is not designed for huge LANs. If you want that you need
> > to make significant changes - http://www.cl.cam.ac.uk/~mas90/MOOSE/
>
> Hm:
>
> "Our object is to design a communication system which can grow smoothly to
> accommodate several buildings full of personal computers and the
On 15 jun 2011, at 18:39, Leo Bicknell wrote:
> Maybe I'm missing something, but the last update on this was RFC
> 5006 I think, which is marked as "experimental", and I thought the
> IETF still had a working group discussing it.
You missed the upgrade to proposed standard:
http://tools.ietf.or
In a message written on Wed, Jun 15, 2011 at 10:22:12AM -0500, Jima wrote:
> Oh, oops; you did touch upon this. You might want to let the people
> who've implemented RDNSS in software know that the IETF is working on
> it. I'm sure that'll be a relief.
Maybe I'm missing something, but the las
On 15 jun 2011, at 16:52, Tony Finch wrote:
> Ethernet is not designed for huge LANs. If you want that you need
> to make significant changes - http://www.cl.cam.ac.uk/~mas90/MOOSE/
Hm:
"Our object is to design a communication system which can grow smoothly to
accommodate several buildings full
On 06/14/2011 03:25 PM, Leo Bicknell wrote:
I urge everyone in this thread to try a simple experiment. Configure
an IPv6 segment in your lab. Make sure there is no IPv4 on it, not
on the router, and that the IPv4 stack (to the extent possible) is
disabled on the hosts. Now try to use one of th
Ricky Beam wrote:
>
> And IPv6 has been designed (poorly, it would now appear) for huge "LAN"s
> -- LANs are supposed to be /64, after all.
Ethernet is not designed for huge LANs. If you want that you need
to make significant changes - http://www.cl.cam.ac.uk/~mas90/MOOSE/
Tony.
--
f.anthony.n.
On 15 jun 2011, at 7:33, Owen DeLong wrote:
> Bottom line, I expect it's easier to get cooperation from OS vendors and BIOS
> vendors to make changes
> because experience has shown that they are more willing to do so than
> vertical software vendors.
> As such, yes, I'd like to see some harmles
On Jun 14, 2011, at 5:50 PM, Ricky Beam wrote:
> On Tue, 14 Jun 2011 18:16:10 -0400, Owen DeLong wrote:
>> The point of /64 is to support automatic configuration and incredibly sparse
>> host addressing.
>> It is not intended to create stupidly large broadcast domains.
>
> Several IETF (and NA
On Jun 14, 2011, at 6:00 PM, Ricky Beam wrote:
> On Tue, 14 Jun 2011 18:44:22 -0400, Iljitsch van Beijnum
> wrote:
>> BTW, does this broken software run over IPv6, anyway?
>
> Poorly designed network plus poorly designed software... I don't know which
> chicken came first, and it doesn't matt
On Jun 14, 2011, at 3:44 PM, Iljitsch van Beijnum wrote:
> On 15 jun 2011, at 0:05, Owen DeLong wrote:
>
>> Yes, the right solution would be to at least separate the VLANs and clean up
>> this
>> mess. However, due to software packages that need to talk to each other over
>> common local broadc
On Jun 13, 2011, at 5:41 PM, Owen DeLong wrote:
>
> On Jun 12, 2011, at 11:12 AM, Iljitsch van Beijnum wrote:
>
>> On 12 jun 2011, at 15:45, Leo Bicknell wrote:
>>
Like I said before, that would pollute the network with many multicasts
which can seriously degrade wifi performance.
>
> > BTW, does this broken software run over IPv6, anyway?
>
> Poorly designed network plus poorly designed software... I don't know
which
> chicken came first, and it doesn't matter.
>
> IPv6 is totally different barnyard. Build the v6 network properly -- one
> gateway (one router, vrrp, whateve
On Jun 10, 2011, at 7:03 PM, Owen DeLong wrote:
> I see no reason that additional DHCPv6 options would have to fragment the
> installed
> base or perpetuate the lack of agreed upon DHCPv6 behavior. In fact, I think
> that
> adding these options could allow for a set of rules that would be accep
On Tue, 14 Jun 2011 18:44:22 -0400, Iljitsch van Beijnum
wrote:
BTW, does this broken software run over IPv6, anyway?
Poorly designed network plus poorly designed software... I don't know
which chicken came first, and it doesn't matter.
IPv6 is totally different barnyard. Build the v6 ne
On Tue, 14 Jun 2011 18:16:10 -0400, Owen DeLong wrote:
The point of /64 is to support automatic configuration and incredibly
sparse host addressing.
It is not intended to create stupidly large broadcast domains.
Several IETF (and NANOG) discussions say otherwise. While current
hardware do
On 15 jun 2011, at 0:05, Owen DeLong wrote:
> Yes, the right solution would be to at least separate the VLANs and clean up
> this
> mess. However, due to software packages that need to talk to each other over
> common local broadcast across that boundary, this isn't possible in this
> particular
On Jun 14, 2011, at 1:30 PM, Ricky Beam wrote:
> On Tue, 14 Jun 2011 04:00:22 -0400, Owen DeLong wrote:
>> You would need an AWFUL lot of hosts for this to add up to a few 100pps (or
>> even 10pps) of multicast traffic.
>
> You're missing the point... most WAPs are horrible with multicast. It
On Jun 14, 2011, at 1:15 PM, Ricky Beam wrote:
> On Tue, 14 Jun 2011 12:02:18 -0400, Owen DeLong wrote:
>> That was kind of my point. You are unlikely to encounter such a large L2
>> domain outside of an exchange point.
>
> I've seen such large networks in private industry (and governements, n
On Jun 14, 2011, at 11:00 AM, Ben Jencks wrote:
> On Jun 14, 2011, at 1:41 PM, Owen DeLong wrote:
>
>> Then use RA and move on. However, please understand that yours
>> is not the only environment and that there are real-world scenarios
>> where having the router-guys dictate the host configurat
On Jun 14, 2011, at 11:14 AM, Ray Soucy wrote:
>> On Jun 14, 2011, at 1:41 PM, Owen DeLong wrote:
>> What is needed is:
>>
>> - Native RA Guard in switches
>> - Native DHCPv6 Snooping in switches
>> - Native RA Guard in WAPs
>> - Native DHCPv6 Snoo
In a message written on Tue, Jun 14, 2011 at 05:01:24PM -0400, Ben Jencks wrote:
> > Lastly, there's a hidden bit here many people haven't dealt with
> > yet in lab networks. In IPv4 critical environments it's typical
> > to use HSRP or VRRP to provide a single gateway across two routers.
> > The
On Jun 14, 2011, at 4:25 PM, Leo Bicknell wrote:
> In a message written on Tue, Jun 14, 2011 at 02:00:35PM -0400, Ben Jencks
> wrote:
>> This has always confused me. What aspect of host configuration is the router
>> providing that's so problematic? The prefix, which has to match on the
>> rou
On Tue, Jun 14, 2011 at 12:41, Ray Soucy wrote:
>
> The energy in this thread should be focused on switch vendors to
> actually implement L2 security features for IPv6, which is usually an
> easy upgrade; rather than calling for all host implementations of IPv6
> to work differently; which will ta
On Tue, 14 Jun 2011 04:00:22 -0400, Owen DeLong wrote:
You would need an AWFUL lot of hosts for this to add up to a few 100pps
(or even 10pps) of multicast traffic.
You're missing the point... most WAPs are horrible with multicast. It
doesn't matter if it's v4 or v6, at L2, multicast is mu
In a message written on Tue, Jun 14, 2011 at 02:00:35PM -0400, Ben Jencks wrote:
> This has always confused me. What aspect of host configuration is the router
> providing that's so problematic? The prefix, which has to match on the router
> and host in order for anything to work anyway? The indi
On Tue, 14 Jun 2011 12:02:18 -0400, Owen DeLong wrote:
That was kind of my point. You are unlikely to encounter such a large L2
domain outside of an exchange point.
I've seen such large networks in private industry (and governements, not
just the US) several times. And IPv6 has been design
> On Jun 14, 2011, at 1:41 PM, Owen DeLong wrote:
> What is needed is:
>
>- Native RA Guard in switches
>- Native DHCPv6 Snooping in switches
>- Native RA Guard in WAPs
>- Native DHCPv6 Snooping in WAPs
>- Additional options to D
On Jun 14, 2011, at 1:41 PM, Owen DeLong wrote:
> Then use RA and move on. However, please understand that yours
> is not the only environment and that there are real-world scenarios
> where having the router-guys dictate the host configuration is considered
> unacceptable at best.
This has alway
On Jun 14, 2011, at 9:41 AM, Ray Soucy wrote:
> The energy in this thread should be focused on switch vendors to
> actually implement L2 security features for IPv6, which is usually an
> easy upgrade; rather than calling for all host implementations of IPv6
> to work differently; which will take
On Jun 14, 2011, at 9:18 AM, Nick Hilliard wrote:
> On 14/06/2011 17:02, Owen DeLong wrote:
>> That was kind of my point. You are unlikely to encounter such a large L2
>> domain outside of an
>> exchange point.
>
> Indeed so. Apart from large enterprise LANs. And campus LANs. And badly
> de
The energy in this thread should be focused on switch vendors to
actually implement L2 security features for IPv6, which is usually an
easy upgrade; rather than calling for all host implementations of IPv6
to work differently; which will take a decade to implement and be a
band-aid at best; not a g
On 14/06/2011 17:02, Owen DeLong wrote:
That was kind of my point. You are unlikely to encounter such a large L2 domain
outside of an
exchange point.
Indeed so. Apart from large enterprise LANs. And campus LANs. And badly
designed large service provider LANs. And other types of large L2 d
On 14/06/2011 16:12, Ray Soucy wrote:
The point was you shouldn't base protocol design around the
possibility that someone might tell it to do something you don't want
it to do; otherwise you'll end up with a one-size-fits-all protocol
that has zero flexibility (and might not even be functional a
On Jun 14, 2011, at 1:48 AM, Mikael Abrahamsson wrote:
> On Tue, 14 Jun 2011, Owen DeLong wrote:
>
>> ND would be a far more frequent occurrence than DHCP requests.
>
> Of course, it was only partly related to the discussion, most likely the
> network which has problem with multicast would bre
Wow, I don't recall making it personal?
I have broken networks before by connecting miss-configured devices,
by the way, and I was a moron for doing so. I don't base my network
design decisions around preventing people with full access to
configure the network breaking it; but rather restrict the
On 14 jun 2011, at 10:20, Mikael Abrahamsson wrote:
> On the AMSIX peering LAN there is more than 100pps of ND traffic (at least
> there was when we checked). Since they do not do IPv6 multicast intelligent
> handling (MLD snooping I guess) certain highend (legacy) router platforms run
> into t
In a message written on Tue, Jun 14, 2011 at 10:20:07AM +0200, Mikael
Abrahamsson wrote:
> On the AMSIX peering LAN there is more than 100pps of ND traffic (at least
> there was when we checked). Since they do not do IPv6 multicast
> intelligent handling (MLD snooping I guess) certain highend (l
On Tue, 14 Jun 2011, Owen DeLong wrote:
ND would be a far more frequent occurrence than DHCP requests.
Of course, it was only partly related to the discussion, most likely the
network which has problem with multicast would break first because of ND,
not because of DHCPv6 requests.
Also, I
On Jun 14, 2011, at 1:20 AM, Mikael Abrahamsson wrote:
> On Tue, 14 Jun 2011, Owen DeLong wrote:
>
>> You would need an AWFUL lot of hosts for this to add up to a few 100pps (or
>> even 10pps) of multicast traffic.
>
> On the AMSIX peering LAN there is more than 100pps of ND traffic (at least
On Tue, 14 Jun 2011, Owen DeLong wrote:
You would need an AWFUL lot of hosts for this to add up to a few 100pps
(or even 10pps) of multicast traffic.
On the AMSIX peering LAN there is more than 100pps of ND traffic (at least
there was when we checked). Since they do not do IPv6 multicast
int
On Jun 13, 2011, at 12:50 PM, Ricky Beam wrote:
> On Sun, 12 Jun 2011 09:45:01 -0400, Leo Bicknell wrote:
>> In a message written on Sun, Jun 12, 2011 at 01:04:41PM +0200, Iljitsch van
>> Beijnum wrote:
>>> Like I said before, that would pollute the network with many multicasts
>>> which can s
On Jun 12, 2011, at 6:42 PM, Jimmy Hess wrote:
> On Sun, Jun 12, 2011 at 8:29 PM, Leo Bicknell wrote:
>> DHCP today uses an exponential backoff if there is no response, I don't
>> see why that can't be kept in IPv6. Plus I wonder how long users would
>> keep on machines that get no useable netw
> -Original Message-
> From: Leo Bicknell [mailto:bickn...@ufp.org]
> Sent: Monday, June 13, 2011 7:55 PM
> To: nanog@nanog.org
> Subject: Re: The stupidity of trying to "fix" DHCPv6
>
[snip]
> I understand on some level why the IETF doesn't want
In a message written on Mon, Jun 13, 2011 at 05:41:12PM -0700, Owen DeLong
wrote:
> > The IPv4 host does this once and gets its lease. If there is no DHCPv6
> > server then DHCPv6 clients would keep broadcasting forever. Not a good
> > thing.
> >
>
> Which is no worse than the behavior of an I
On Jun 12, 2011, at 11:12 AM, Iljitsch van Beijnum wrote:
> On 12 jun 2011, at 15:45, Leo Bicknell wrote:
>
>>> Like I said before, that would pollute the network with many multicasts
>>> which can seriously degrade wifi performance.
>
>> Huh? This is no worse than IPv4 where a host comes up
> -Original Message-
> From: Jimmy Hess [mailto:mysi...@gmail.com]
> Sent: Sunday, June 12, 2011 8:43 PM
> To: nanog@nanog.org
> Subject: Re: The stupidity of trying to "fix" DHCPv6
>
> On Sun, Jun 12, 2011 at 8:29 PM, Leo Bicknell wrote:
> > DHCP
On Jun 12, 2011, at 4:04 AM, Iljitsch van Beijnum wrote:
> On 12 jun 2011, at 12:35, Daniel Roesen wrote:
>
>> Could you point to any RFC which implies or explicitly states that
>> DHCPv6 MUST NOT be used in absence of RA with M and/or O=1?
>
> But what's the alternative? Always run DHCPv6 even
On Jun 12, 2011, at 4:01 AM, Iljitsch van Beijnum wrote:
> On 11 jun 2011, at 17:05, Owen DeLong wrote:
>
>>> Your doctor doesn't just give you the medicine you ask for either.
>
>> You are not talking about a doctor/patient scenario here where the doctor is
>> an expert and the people asking
On Jun 13, 2011, at 12:50 PM, Ricky Beam wrote:
> On Sun, 12 Jun 2011 09:45:01 -0400, Leo Bicknell wrote:
>> In a message written on Sun, Jun 12, 2011 at 01:04:41PM +0200, Iljitsch van
>> Beijnum wrote:
>>> Like I said before, that would pollute the network with many multicasts
>>> which can s
On Sun, 12 Jun 2011 09:45:01 -0400, Leo Bicknell wrote:
In a message written on Sun, Jun 12, 2011 at 01:04:41PM +0200, Iljitsch
van Beijnum wrote:
Like I said before, that would pollute the network with many multicasts
which can seriously degrade wifi performance.
Huh? This is no worse tha
On Sun, Jun 12, 2011 at 8:29 PM, Leo Bicknell wrote:
> DHCP today uses an exponential backoff if there is no response, I don't
> see why that can't be kept in IPv6. Plus I wonder how long users would
> keep on machines that get no useable network connectivity.
>
> I really think the number of bro
In a message written on Sun, Jun 12, 2011 at 08:12:02PM +0200, Iljitsch van
Beijnum wrote:
> The IPv4 host does this once and gets its lease. If there is no DHCPv6 server
> then DHCPv6 clients would keep broadcasting forever. Not a good thing.
DHCP today uses an exponential backoff if there is n
On Sun, Jun 12, 2011 at 08:12:02PM +0200, Iljitsch van Beijnum wrote:
> On 12 jun 2011, at 15:45, Leo Bicknell wrote:
>
> >> Like I said before, that would pollute the network with many multicasts
> >> which can seriously degrade wifi performance.
>
> > Huh? This is no worse than IPv4 where a h
Op 12 jun 2011, om 12:05 heeft Daniel Roesen het volgende geschreven:
> VRRP communications itself is via link-local addresses. There is a
> requirement to have a link-local virtual address as well, but there
> might be many more, e.g. global scope.
In FreeBSD with pfSense I use CARP with a v6 a
On 6/12/2011 4:01 AM, Iljitsch van Beijnum wrote:
IPv6 address configuration is a house of cards. Touch it and it all comes
crashing down. DHCPv6 has a number of significant flaws, and the interaction
between DHCPv6 and router advertisements only barely makes sense.
Well, at least you're bein
On 12 jun 2011, at 15:45, Leo Bicknell wrote:
>> Like I said before, that would pollute the network with many multicasts
>> which can seriously degrade wifi performance.
> Huh? This is no worse than IPv4 where a host comes up and sends a
> subnet-broadcast to get DHCP.
The IPv4 host does this
And networks without RAs are very common. We call those networks "IPv4-only
networks".
No, we call those server networks. I've seen lots of IPv6 networks with
RA's disabled and all static devices on them. Sometimes having hosts
dynamically get addresses and default routes is a bad thing.
On Sun, Jun 12, 2011 at 01:04:41PM +0200, Iljitsch van Beijnum wrote:
> On 12 jun 2011, at 12:35, Daniel Roesen wrote:
>
> > Could you point to any RFC which implies or explicitly states that
> > DHCPv6 MUST NOT be used in absence of RA with M and/or O=1?
>
> But what's the alternative? Always ru
In a message written on Sun, Jun 12, 2011 at 01:04:41PM +0200, Iljitsch van
Beijnum wrote:
> But what's the alternative? Always run DHCPv6 even if there are no router
> advertisements or router advertisements with O=0, M=0?
Yes.
> Like I said before, that would pollute the network with many mul
On 12 jun 2011, at 12:35, Daniel Roesen wrote:
> Could you point to any RFC which implies or explicitly states that
> DHCPv6 MUST NOT be used in absence of RA with M and/or O=1?
But what's the alternative? Always run DHCPv6 even if there are no router
advertisements or router advertisements with
On 11 jun 2011, at 17:05, Owen DeLong wrote:
>> Your doctor doesn't just give you the medicine you ask for either.
> You are not talking about a doctor/patient scenario here where the doctor is
> an expert and the people asking for this have no
> medical training. Here, we are talking about requ
On 11 jun 2011, at 16:39, David Conrad wrote:
>> There is no point in repeating all the IPv4 mistakes with IPv6, if that's
>> what you want, stay on IPv4.
> As should be apparent by now, the vast majority of people don't want to move
> to IPv6. They simply want access to "the Internet". ISPs a
On Fri, Jun 10, 2011 at 09:12:26PM -0700, Owen DeLong wrote:
> You must have RA to at least tell you:
> Default Router
> Go ask the DHCP server (M and/or O bit)
>
> As it currently stands, an RFC-compliant host will not attempt to solicit
> a DHCP response unless it receives an RA with
On Sat, Jun 11, 2011 at 12:41:17PM -0400, Kevin Loch wrote:
> VRRPv3 (http://tools.ietf.org/html/rfc5798) is still a bit broken
> in that it makes mention of "MUST advertise RA's"
That's unintentional as per recent discussion on IETF VRRP mailing list
where I seeked for clarification as JUNOS comp
On 2011-06-10 21:03, Owen DeLong wrote:
On Jun 10, 2011, at 12:57 PM, Iljitsch van Beijnum wrote:
I just wish someone had said the same when it was decided that .ip6.int in
reverse DNS zone files was ugly and needed to be changed to .ip6.arpa. Or when
someone decided that it's a good idea to s
Subject: Re: The stupidity of trying to "fix" DHCPv6
I really beieve this is going to be the single largest impediment to
deploying _end user_ IPv6.
--
Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Leo Bicknell wrote:
In a message written on Fri, Jun 10, 2011 at 05:13:09PM +0200, Iljitsch van
Beijnum wrote:
Now you could argue that the DHCPv6-supplied gateway addresses should have
higher priority than the ones learned from RAs. At least that solves the
problem. However, that solution st
I'm sorry, but IPv4 DHCP was a wonderful solution to many issues, which are
very very difficult in IPv6. RA is a solution looking for an actual problem.
That being said, I like having the option of RA, but it is only useful in a
very small subset of use cases, many it actually causes issues, instea
On Jun 11, 2011, at 7:21 AM, Iljitsch van Beijnum wrote:
> On 11 jun 2011, at 4:03, Owen DeLong wrote:
>
>> You can call that bad network design if you want, but, there are real world
>> requirements and scenarios where that has to happen for a variety of reasons.
>
>> Those networks have work
Iljitsch,
On Jun 11, 2011, at 7:21 AM, Iljitsch van Beijnum wrote:
> There is no point in repeating all the IPv4 mistakes with IPv6, if that's
> what you want, stay on IPv4.
As should be apparent by now, the vast majority of people don't want to move to
IPv6. They simply want access to "the In
On 11 jun 2011, at 4:03, Owen DeLong wrote:
> You can call that bad network design if you want, but, there are real world
> requirements and scenarios where that has to happen for a variety of reasons.
> Those networks have working configurations in DHCPv4 and no ability to move
> to IPv6
> unt
On Jun 10, 2011, at 8:36 PM, Matthew Reath wrote:
>
>> This is "different types of networks and network users" and also different
>> operational, administrative, and security domains.
>>
>> I am also getting frustrated with the endless discussions that could be
>> immediately shortened by "tink
On Fri, Jun 10, 2011 at 07:53:36AM -0700, Owen DeLong wrote:
> On Jun 10, 2011, at 7:47 AM, Leo Bicknell wrote:
> > In a message written on Fri, Jun 10, 2011 at 10:34:57AM -0400, Ray Soucy
> > wrote:
> >> Also agree that I want flexibility to use RA or DHCPv6; the
> >> disagreement is that RA need
> This is "different types of networks and network users" and also different
> operational, administrative, and security domains.
>
> I am also getting frustrated with the endless discussions that could be
> immediately shortened by "tinkering with DHCP" to add one or two
> additional options -- a
On Jun 10, 2011, at 10:21 PM, George Herbert wrote:
> On Fri, Jun 10, 2011 at 7:03 PM, Owen DeLong wrote:
>>> And like I said before, we have more pressing things to do than tinker some
>>> more with DHCPv6.
>>
>> Meh... We can achieve a big win for relatively low cost very quickly and
>> mak
On Fri, Jun 10, 2011 at 7:03 PM, Owen DeLong wrote:
>> And like I said before, we have more pressing things to do than tinker some
>> more with DHCPv6.
>
> Meh... We can achieve a big win for relatively low cost very quickly and make
> IPv6 much
> more palatable to a wide audience of enterprise
On Jun 10, 2011, at 12:57 PM, Iljitsch van Beijnum wrote:
> On 10 jun 2011, at 18:06, Leo Bicknell wrote:
>
>> However, many networks are much more closed deployments. Enterprises
>> have not deployed IPv6 internally yet. Many will not deploy it for
>> another 3-5 years, chosing instead to use
On Jun 10, 2011, at 11:18 AM, valdis.kletni...@vt.edu wrote:
> On Fri, 10 Jun 2011 12:54:17 CDT, Jima said:
>> If we go down this path, how long before we hear screaming about rogue
>> DHCPv6 servers giving v4-only networks a false v6 path?
>
> Already happened. Good way to install an MITM aga
On 10 jun 2011, at 23:30, Rhys Rhaven wrote:
> And here I thought with IPv6, we would have learned from our mistakes,
> fixed those problems. We've had 15 years to think about it. I was
> looking forward to a future where ICMPv6 might even be used.
What are you talking about??
ICMPv6 does what I
And here I thought with IPv6, we would have learned from our mistakes,
fixed those problems. We've had 15 years to think about it. I was
looking forward to a future where ICMPv6 might even be used.
At this point I'm looking forward to IPv6 being the bane of my career
for the next 5 years.
On 06/1
On Jun 10, 2011, at 12:21 PM, Steve Clark wrote:
> On 06/10/2011 09:37 AM, Ray Soucy wrote:
>> You really didn't just write an entire post saying that RA is bad
>> because if a moron of a network engineer plugs an incorrectly
>> configured device into a production network it may cause problems, d
On Fri, 10 Jun 2011 13:27:58 PDT, Leo Bicknell said:
> The funny thing is, no one does this anymore. We turned off RIP,
> turned off routed, and invented things like HSRP to handle router
> redundancy. These things weren't done because someone was bored,
> no, they were done because these RIP dep
In a message written on Fri, Jun 10, 2011 at 09:57:07PM +0200, Iljitsch van
Beijnum wrote:
> If only. Having third parties point to routers is less robust than having
> routers announce their own presence. In the telco world, there's a separation
> between the control and data channels, which ha
On Fri, 10 Jun 2011 09:47:44 -0400, Leo Bicknell wrote:
The point is, RA's are operationally fragile and DHCP is operationally
robust.
No. Both are just as fragile... if you haven't taken steps to protect
them. If you aren't doing any sort of DHCP snooping, anyone can setup a
rogue DHCP
On 10 jun 2011, at 18:06, Leo Bicknell wrote:
> However, many networks are much more closed deployments. Enterprises
> have not deployed IPv6 internally yet. Many will not deploy it for
> another 3-5 years, chosing instead to use web proxies at the edge
> that speak IPv4 (RFC1918) internally and
On Fri, Jun 10, 2011 at 2:21 PM, Steve Clark wrote:
> On 06/10/2011 09:37 AM, Ray Soucy wrote:
>>
>> You really didn't just write an entire post saying that RA is bad
>> because if a moron of a network engineer plugs an incorrectly
>> configured device into a production network it may cause proble
On 06/10/2011 09:37 AM, Ray Soucy wrote:
You really didn't just write an entire post saying that RA is bad
because if a moron of a network engineer plugs an incorrectly
configured device into a production network it may cause problems, did
you?
You are the moron - this stuff happens and wishin
1 - 100 of 143 matches
Mail list logo
