Mailing List Archive: NANOG: users

IPv6 Deployment for the LAN

1 2 3 4 5 6 7

View All

Index | Next | Previous | View Threaded

mohacsi at niif

Oct 22, 2009, 5:25 AM

Post #76 of 151 (743 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On Thu, 22 Oct 2009, bmanning [at] vacation wrote:

> On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote:
>> On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote:
>>> If, on the other hand, the REAL desire is to have a DHCP server break
>>> the tie in the selection between several routers that advertise their
>>> presence, that wouldn't be unreasonable.
>>
>> The RA contains a preference level... maybe that doesn't cut it if
>> multiple routers are sending the same preference level, but presumably
>> that would not happen in a well-tended network.
>
> I point you to a fairly common Internet architecture artifact,
> the exchange point... dozens of routers sharing a common
> media for peering exchange.

And you want to use router advertisments for assigning addresses for them?
Huh!

Regards,
Janos

trejrco at gmail

Oct 22, 2009, 5:32 AM

Post #77 of 151 (741 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53?

... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve FD00::/96 for this type of "ULA port-based anycast allocation". (16bits would only reach 9999 w/o hex-conversion (if hex-converted could reserve FD00::/112 ... But would be less obvious))

Easily identified, not globally routable, can be pre-programmed in implementations/applications ... ?

... Just thinking 'out loud' ...
/TJ
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Perry Lorier <perry [at] coders>
Date: Fri, 23 Oct 2009 00:22:52
To: <bmanning [at] vacation>
Cc: <nanog [at] nanog>
Subject: Re: IPv6 Deployment for the LAN

bmanning [at] vacation wrote:
> On Thu, Oct 22, 2009 at 12:02:14PM +0200, Iljitsch van Beijnum wrote:
>
>> On 22 okt 2009, at 01:55, bmanning [at] vacation wrote:
>>
>>
>>> so your not a fan of the smart edge and the stupid network.
>>>
>> I'm a fan of getting things right. A server somewhere 5 subnets away
>> doesn't really know what routers are working on my subnet. It can take
>> a guess and then wait for people to complain and then an admin to fix
>> stuff if the guess is wrong, but I wouldn't call that a "smart edge".
>>
>> Always learn information from the place where it's actually known.
>>
>
> i'm ok w// that mindset.
>
> one should learn routing from the router(s),
> time from the time servers,
> DNS from the DNS servers,
> etc...
>
>

I quite liked the old
http://tools.ietf.org/html/draft-ietf-ipv6-dns-discovery-07 idea.
(tl;dr version: Have a set of well known site local anycast address for
recursive name servers). It has a number of nice features such as:

* since it's not in globally routable space people can't (ab)use your
recursive name servers from outside your network.
* you don't have to change recursive name servers when going to a
different network -- they're the same everywhere.
* the addresses can be set as the default addresses by the OS
manufacturer, and then don't need to be configured ever again.
* If your recursive name server becomes unreachable, broken or otherwise
out of contact, it withdraws the address from your IGP, then since you
can any cast these addresses, another node takes over. Similar to the
shared fate idea of RA's.
* You don't tie your recursive nameservers addresses to any point in the
network, since they have their own special range, moving them,
reshuffling them, or anything doesn't impact anything. They don't need
to cohabit a router sending RA's or anything odd like that.

However it has a number of obvious drawbacks, primarily amongst them
being that it uses deprecated site local addresses.

You could imagine extending this to other services such as NTP, but I'm
not sure that you really would want to go that far, perhaps using DNS to
lookup "_ntp._udp.local IN SRV" or similar to find your local NTP servers.

Another obvious approach might be to have a service discovery protocol
where you send to a "service discovery" multicast group a message asking
"wheres the nearest nameserver(s)?" then nameserver implementations
could listen on this multicast group and reply. Again shared fate.
This does have the downside of people running rogue nameservers and
needing a "ServiceDiscovery-Guard" feature for switches....

Personally I like the first option (anycast addresses) better, you can
control who has access to your IGP and if your IGP is down, then for all
intents and purposes your recursive nameservers are offline too :)

kauer at biplane

Oct 22, 2009, 5:36 AM

Post #78 of 151 (741 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On Thu, 2009-10-22 at 14:25 +0200, Mohacsi Janos wrote:
> On Thu, 22 Oct 2009, bmanning [at] vacation wrote:
> > I point you to a fairly common Internet architecture artifact,
> > the exchange point... dozens of routers sharing a common
> > media for peering exchange.
>
> And you want to use router advertisments for assigning addresses for them?
> Huh!

You've got the wrong end of the stick. The point of this exchange was
that RA was not going to do the job.

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer [at] biplane) +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/ +61-428-957160 (mob)

GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF

Attachments:

signature.asc (0.19 KB)

nick at foobar

Oct 22, 2009, 5:45 AM

Post #79 of 151 (742 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On 22/10/2009 12:49, bmanning [at] vacation wrote:
> its been a few weeks/years/minutes since I ran an exchange fabric,
> but when we first turned up IPv6 - the first thing they did was try
> to hand all the other routers IPv6 addresses. that pesky RA/ND
> thing... had to turn it off ... RA preference would not work, since
> there was no -pecking- order - all the routers were peers.

Bill, I am not able to look at this paragraph without being reminded of
Charles Babbage's take on the GIGO principal:

"On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into
the machine wrong figures, will the right answers come out?' I am not able
rightly to apprehend the kind of confusion of ideas that could provoke such
a question."

Nick

kloch at kl

Oct 22, 2009, 8:03 AM

Post #80 of 151 (741 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

Iljitsch van Beijnum wrote:

> If, on the other hand, the REAL desire is to have a DHCP server break
> the tie in the selection between several routers that advertise their
> presence, that wouldn't be unreasonable.

In some configurations not all hosts are supposed to use the same
router. We need the _option_ to specify a default gateway and
have the override any RA's a host may see.

> There is no requirement that the IETF provides all functionality that
> someone can think up. The list of desired functionality is infinite, and
> much on that list is a bad idea and/or can be achieved in different ways.

Ok, lets start with not breaking the functionality we have today
in IPv4. Once you get that working again we can look at new
ideas (like RA) that might have utility. Let the new stuff live/die on
it's own merits. The Internet is very good at sorting out the useful
technology from the crap.

>> Seriously, we're all adults. So treating us like children and taking
>> away
>> the power tools is not appreciated.
>
> Stop trying to break the internet and I'll treat you like an adult.

At conferences I keep hearing "It would be great if the IETF had
more operator input." Yet whenever we try to provide operationally
useful advice we are ridiculed for not being smart enough to know
how things should work.

How do we fix that?

- Kevin

drc at virtualized

Oct 22, 2009, 8:22 AM

Post #81 of 151 (740 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

> Ok, lets start with not breaking the functionality we have today
> in IPv4. Once you get that working again we can look at new
> ideas (like RA) that might have utility. Let the new stuff live/die on
> it's own merits. The Internet is very good at sorting out the useful
> technology from the crap.

Right. I'll admit some confusion here. If the IETF, due to religion or aesthetics, is blocking attempts at making DHCPv6 do what network operators _need_ (as opposed to want), why haven't network operators routed around the problem and gone and funded folks like ISC, NLNetLabs, Cisco, Juniper, et al., to implement what they need?

> At conferences I keep hearing "It would be great if the IETF had
> more operator input." Yet whenever we try to provide operationally
> useful advice we are ridiculed for not being smart enough to know
> how things should work.
>
> How do we fix that?

You seem to be asking "how do we make people not stupid". Folks tend to simplify reality so that it fits their world view. Stupid people attempt to force that simplified reality onto others. You can either play their game, attempting to get them to understand reality is often more complicated than we'd like, or route around them. Or you can post to NANOG... :-)

Regards,
-drc

iljitsch at muada

Oct 22, 2009, 8:44 AM

Post #82 of 151 (740 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On 22 okt 2009, at 17:03, Kevin Loch wrote:

>> If, on the other hand, the REAL desire is to have a DHCP server
>> break the tie in the selection between several routers that
>> advertise their presence, that wouldn't be unreasonable.

> In some configurations not all hosts are supposed to use the same
> router. We need the _option_ to specify a default gateway and
> have the override any RA's a host may see.

Lots of people "need" a gun. If I were living in a place where bears
walk around loose I might "need" one, too. But most guns are used to
shoot the owner in the foot most of the time. The world would be a
better place without them.

Like I said, if there's a bunch of routers announcing their presence
and you want a DHCP option to provide guidance to a host as to which
one to choose, that would be fine. But pointing to a potentially non-
existing address in the hopes that there will magically be a router
residing at that address would a serious regression in robustness.

>> There is no requirement that the IETF provides all functionality
>> that someone can think up. The list of desired functionality is
>> infinite, and much on that list is a bad idea and/or can be
>> achieved in different ways.

> Ok, lets start with not breaking the functionality we have today
> in IPv4. Once you get that working again we can look at new
> ideas (like RA) that might have utility.

What does that have to with anything? IPv6 stateless autoconfig
predates the widespread use of DHCPv4.

> Let the new stuff live/die on
> it's own merits. The Internet is very good at sorting out the useful
> technology from the crap.

Absolutely not. Give users the choice between something good that
suits their needs 83% and a piece of crap tht suits their needs 84%
and they'll choose the latter each and every time.

Users get to say what they need. They don't get to design the solution
by committee any more than they get to design bridges or airplanes by
committee, although of course they do get to choose which ones to use.

> At conferences I keep hearing "It would be great if the IETF had
> more operator input." Yet whenever we try to provide operationally
> useful advice we are ridiculed for not being smart enough to know
> how things should work.

> How do we fix that?

Tell the IETF your real requirements, don't try to do back seat
protocol design. Protocol design is hard, the IETF gets it wrong most
of the time (and they do better than some of their colleagues, still).
Suggesting specific changes to a protocol as a solution to an unstated
real requirement wastes everyone's time.

With writing, they tell you "listen when people say there is a
problem, but ignore them when they tell you what the problem is". Same
thing here. Users know their needs, but generally they don't know the
best way to meet those needs.

adrian at creative

Oct 22, 2009, 8:55 AM

Post #83 of 151 (741 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On Thu, Oct 22, 2009, Iljitsch van Beijnum wrote:

> What does that have to with anything? IPv6 stateless autoconfig
> predates the widespread use of DHCPv4.

So does IPX and IPX/RIP.

Why does this thread seem to rehash some big disconnect between
academics, IETF and actual deployment-oriented people who have
a job to do?

Silly architecture groups..

Adrian
(Glad I'm not involved. I'd lose patience and punch people.)

owen at delong

Oct 22, 2009, 11:10 AM

Post #84 of 151 (733 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On Oct 22, 2009, at 8:44 AM, Iljitsch van Beijnum wrote:

> On 22 okt 2009, at 17:03, Kevin Loch wrote:
>
>>> If, on the other hand, the REAL desire is to have a DHCP server
>>> break the tie in the selection between several routers that
>>> advertise their presence, that wouldn't be unreasonable.
>
>> In some configurations not all hosts are supposed to use the same
>> router. We need the _option_ to specify a default gateway and
>> have the override any RA's a host may see.
>
> Lots of people "need" a gun. If I were living in a place where bears
> walk around loose I might "need" one, too. But most guns are used to
> shoot the owner in the foot most of the time. The world would be a
> better place without them.
>
As a strong proponent of the second amendment, it is now clear to me
that we have a fundamental disagreement on how society should
interoperate which is unlikely to ever be resolved between us.

> Like I said, if there's a bunch of routers announcing their presence
> and you want a DHCP option to provide guidance to a host as to which
> one to choose, that would be fine. But pointing to a potentially non-
> existing address in the hopes that there will magically be a router
> residing at that address would a serious regression in robustness.
>
It really isn't a serious regression in robustness in the real world.
It really is functioning today. Most DHCP servers are not used to
shoot users in the head, despite your claims to the contrary.

>>> There is no requirement that the IETF provides all functionality
>>> that someone can think up. The list of desired functionality is
>>> infinite, and much on that list is a bad idea and/or can be
>>> achieved in different ways.
>
>> Ok, lets start with not breaking the functionality we have today
>> in IPv4. Once you get that working again we can look at new
>> ideas (like RA) that might have utility.
>
> What does that have to with anything? IPv6 stateless autoconfig
> predates the widespread use of DHCPv4.
>
Hmmm... Perhaps you should be asking yourself why IPv6 SLAAC was not
used as the model for address assignment in IPv4 instead of DHCPv4 in
that case?

>> Let the new stuff live/die on
>> it's own merits. The Internet is very good at sorting out the useful
>> technology from the crap.
>
> Absolutely not. Give users the choice between something good that
> suits their needs 83% and a piece of crap tht suits their needs 84%
> and they'll choose the latter each and every time.
>
Yes... As well they should. Meeting their needs 84% of the time is
actually vastly superior.

> Users get to say what they need. They don't get to design the
> solution by committee any more than they get to design bridges or
> airplanes by committee, although of course they do get to choose
> which ones to use.
>
Depends on how you define users. If you don't think that airlines
have a substantial amount of technical input into how airliners are
designed, you are vastly mistaken.

>> At conferences I keep hearing "It would be great if the IETF had
>> more operator input." Yet whenever we try to provide operationally
>> useful advice we are ridiculed for not being smart enough to know
>> how things should work.
>
>> How do we fix that?
>
> Tell the IETF your real requirements, don't try to do back seat
> protocol design. Protocol design is hard, the IETF gets it wrong
> most of the time (and they do better than some of their colleagues,
> still). Suggesting specific changes to a protocol as a solution to
> an unstated real requirement wastes everyone's time.
>
> With writing, they tell you "listen when people say there is a
> problem, but ignore them when they tell you what the problem is".
> Same thing here. Users know their needs, but generally they don't
> know the best way to meet those needs.

OK... Here's the real requirement:

Systems administrators who do not control routers need the ability in
a dynamic host configuration mechanism to
assign a number of parameters to the hosts they administer through
that dynamic configuration mechanism. These
parameters include, but, are not limited to:

1. Default Router
2. DNS Resolver information
3. Host can provide name to server so server can supply dynamic DNS
update
4. IP Address(es) (v4, v6, possibly multiple v6 in the case of things
like Shim6, etc.)
5. NTP servers
6. Boot server
7. Site specific attribute/value pairs (ala DHCPv4 Options)

These assignments MUST be controlled by a server and not by the router
because the router is outside of the
administrative control of the Systems Administrator responsible for
the hosts being configured.

Owen

sthaug at nethelp

Oct 22, 2009, 11:51 AM

Post #85 of 151 (735 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

> > Like I said, if there's a bunch of routers announcing their presence
> > and you want a DHCP option to provide guidance to a host as to which
> > one to choose, that would be fine. But pointing to a potentially non-
> > existing address in the hopes that there will magically be a router
> > residing at that address would a serious regression in robustness.
> >
> It really isn't a serious regression in robustness in the real world.
> It really is functioning today. Most DHCP servers are not used to
> shoot users in the head, despite your claims to the contrary.

This to me is one of the least credible claims of the RA/SLAAC crowd.
On the one hand we have carriers around the world with millions and
millions of customers getting default routes and other config through
DHCPv4 every day. And most of the time it actually works very well!

On the other hand we have RA/SLAAC with a vastly smaller customer
base, vastly less real life testing - but which is still claimed to
be so much better that DHCPv6 is not *allowed* to get a default route
option.

The mind boggles.

Steinar Haug, Nethelp consulting, sthaug [at] nethelp

vasil at ludost

Oct 22, 2009, 12:03 PM

Post #86 of 151 (733 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

В 11:10 -0700 на 22.10.2009 (чт), Owen DeLong написа:

> OK... Here's the real requirement:
>
> Systems administrators who do not control routers need the ability in
> a dynamic host configuration mechanism to
> assign a number of parameters to the hosts they administer through
> that dynamic configuration mechanism. These
> parameters include, but, are not limited to:
>
> 1. Default Router
> 2. DNS Resolver information
> 3. Host can provide name to server so server can supply dynamic DNS
> update
> 4. IP Address(es) (v4, v6, possibly multiple v6 in the case of things
> like Shim6, etc.)
> 5. NTP servers
> 6. Boot server
> 7. Site specific attribute/value pairs (ala DHCPv4 Options)
>
> These assignments MUST be controlled by a server and not by the router
> because the router is outside of the
> administrative control of the Systems Administrator responsible for
> the hosts being configured.
>

And to add a real-world case for this - two months ago at HAR (hacking
at random, a convention in the Netherlands) I was in the network team,
handling fun stuff like DHCP servers, DNS, etc.. We also provided IPv6
connectivity there (we had a /16 IPv4 zone and a /48 IPv6 zone), and at
some point we asked the question around - ok, how should we provide DNS
and other useful information for the V6 only people?

After a while with all the brains around, the decision was to write it
on the datenklos through the field, where people can read it and
configure it in their browsers. This would've been funny if it wasn't so
sad.

OTOH, for V4 everything with the DHCP worked fine (as it has always
done, even at an event of this size), as is my experience with all the
networks I've administered. Saying that DHCP doesn't work for me is
extremely weird, as to me this means someone made specific effort to
fuck it up.

Finally - we have something that works, that's called DHCP. It might not
be perfect, it might have some weird issues and implementations, but
it's actually making our lives easier, is tested and works. I'd love
anything that would be better, but as an option, not as the only choice
I have.
And it's not just the protocol that I care about. I care about that it's
implemented in a HOST, where I can play with the software as much as
possible, instead on a ROUTER, which is a vastly different device with
rarely-updated OS, and even in the case where they're both the same
machine(as in small office environments), they're again handled at
different layers (kernel vs userspace).
There are reasons that we're using what we're using, and not all of them
are "because we're masochistic idiots".

--
Regards,
Vasil Kolev

Attachments:

signature.asc (0.19 KB)

james.cutler at consultant

Oct 22, 2009, 12:22 PM

Post #87 of 151 (733 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On Oct 22, 2009, at 3:03 PM, Vasil Kolev wrote:

> В 11:10 -0700 на 22.10.2009 (чт), Owen DeLong написа:
>
>> OK... Here's the real requirement:
>>
>> Systems administrators who do not control routers need the ability in
>> a dynamic host configuration mechanism to
>> assign a number of parameters to the hosts they administer through
>> that dynamic configuration mechanism. These
>> parameters include, but, are not limited to:
>>
>> 1. Default Router
>> 2. DNS Resolver information
>> 3. Host can provide name to server so server can supply dynamic DNS
>> update
>> 4. IP Address(es) (v4, v6, possibly multiple v6 in the case of
>> things
>> like Shim6, etc.)
>> 5. NTP servers
>> 6. Boot server
>> 7. Site specific attribute/value pairs (ala DHCPv4 Options)
>>
>> These assignments MUST be controlled by a server and not by the
>> router
>> because the router is outside of the
>> administrative control of the Systems Administrator responsible for
>> the hosts being configured.
>>
>
>
> And to add a real-world case for this - two months ago at HAR (hacking
> at random, a convention in the Netherlands) I was in the network team,
> handling fun stuff like DHCP servers, DNS, etc.. We also provided IPv6
> connectivity there (we had a /16 IPv4 zone and a /48 IPv6 zone), and
> at
> some point we asked the question around - ok, how should we provide
> DNS
> and other useful information for the V6 only people?
>
> After a while with all the brains around, the decision was to write it
> on the datenklos through the field, where people can read it and
> configure it in their browsers. This would've been funny if it
> wasn't so
> sad.
>
> OTOH, for V4 everything with the DHCP worked fine (as it has always
> done, even at an event of this size), as is my experience with all the
> networks I've administered. Saying that DHCP doesn't work for me is
> extremely weird, as to me this means someone made specific effort to
> fuck it up.
>
> Finally - we have something that works, that's called DHCP. It might
> not
> be perfect, it might have some weird issues and implementations, but
> it's actually making our lives easier, is tested and works. I'd love
> anything that would be better, but as an option, not as the only
> choice
> I have.
> And it's not just the protocol that I care about. I care about that
> it's
> implemented in a HOST, where I can play with the software as much as
> possible, instead on a ROUTER, which is a vastly different device with
> rarely-updated OS, and even in the case where they're both the same
> machine(as in small office environments), they're again handled at
> different layers (kernel vs userspace).
> There are reasons that we're using what we're using, and not all of
> them
> are "because we're masochistic idiots".
>
>
> --
> Regards,
> Vasil Kolev

Following on the comments above:

The security domain for HOST should not overlap the security domain
for ROUTER.

That is the primary driver of the separate administration of HOST and
ROUTER. Heaven help us if the latest M$ virus, or even social-
engineering distributed malware began to affect BGP!

Give the router managers the NTP server addresses and their DHCP
forwarding list and leave them alone to produce a robust and reliable
transport facility!

James R. Cutler
james.cutler [at] consultant

rps at maine

Oct 22, 2009, 12:23 PM

Post #88 of 151 (731 views)
Permalink

Re: {SPAM?} Re: IPv6 Deployment for the LAN [In reply to]

> This to me is one of the least credible claims of the RA/SLAAC crowd.
> On the one hand we have carriers around the world with millions and
> millions of customers getting default routes and other config through
> DHCPv4 every day. And most of the time it actually works very well!
>
> On the other hand we have RA/SLAAC with a vastly smaller customer
> base, vastly less real life testing - but which is still claimed to
> be so much better that DHCPv6 is not *allowed* to get a default route
> option.

If the argument against RA being used to provide gateway information
is "rogue RA," then announcing gateway information though the use of
DHCPv6 doesn't solve anything. Sure you'll get around rogue RA, but
you'll still have to deal with rogue DHCPv6. So what is gained?

I guess I'm not really seeing the case here. Are people really making
use of DHCP to provide hosts on the same network with different
default gateway information? If so, why?

Or is it that you want IPv6 to be a 128-bit version of IPv4? RA is a
good idea and it works. You can add options to DHCPv6, but I don't
see many vendors implementing default gateway support unless you can
make a real case for it.

My fear is that your goal is to do away with RA completely and turn to
DHCPv6 for all configuration. RA is actually quite nice. You really
need to stop fighting it, because it's not going away.

--

Ray Soucy
Communications Specialist

+1 (207) 561-3526

Communications and Network Services

University of Maine System
http://www.maine.edu/

bicknell at ufp

Oct 22, 2009, 12:29 PM

Post #89 of 151 (731 views)
Permalink

Re: {SPAM?} Re: IPv6 Deployment for the LAN [In reply to]

In a message written on Thu, Oct 22, 2009 at 03:23:13PM -0400, Ray Soucy wrote:
> If the argument against RA being used to provide gateway information
> is "rogue RA," then announcing gateway information though the use of
> DHCPv6 doesn't solve anything. Sure you'll get around rogue RA, but
> you'll still have to deal with rogue DHCPv6. So what is gained?

It's a huge difference, and any conference network shows it.

Let's assume 400 people come into a room, get up and working (with
DHCPv4, and IPv6 RA's).

Someone now introduces a rogue IPv4 server. Who breaks? Anyone who
requests a new lease. That is 400 people keep working just fine.

Now, someone introduces a roge RA. Who breaks? All 400 users are
instantly down.

More importantly, there is another class of misconfigured device. I
plugged in a Cisco router to download new code to it on our office
network. It had a DHCP forward statement, and IPv6. It was from
another site.

The DHCP forward didn't work, it pointed to something non-existant that
also was never configured for the local subnet. There was zero chance
of IPv4 interfearance.

The IPv6 network picked up the RA to a router with no routes though, and
so simply plugging in the old router took down the entire office
network.

The operational threats of a DHCP based network and a RA based network
are quite different. Try it on your own network.

--
Leo Bicknell - bicknell [at] ufp - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

alh-ietf at tndh

Oct 22, 2009, 12:41 PM

Post #90 of 151 (730 views)
Permalink

RE: IPv6 Deployment for the LAN [In reply to]

David Conrad wrote:
> > Ok, lets start with not breaking the functionality we have today
> > in IPv4. Once you get that working again we can look at new
> > ideas (like RA) that might have utility. Let the new stuff live/die
> on
> > it's own merits. The Internet is very good at sorting out the useful
> > technology from the crap.
>
> Right. I'll admit some confusion here. If the IETF, due to religion
> or aesthetics, is blocking attempts at making DHCPv6 do what network
> operators _need_ (as opposed to want), why haven't network operators
> routed around the problem and gone and funded folks like ISC,
> NLNetLabs, Cisco, Juniper, et al., to implement what they need?
>
> > At conferences I keep hearing "It would be great if the IETF had
> > more operator input." Yet whenever we try to provide operationally
> > useful advice we are ridiculed for not being smart enough to know
> > how things should work.
> >
> > How do we fix that?
>
> You seem to be asking "how do we make people not stupid". Folks tend
> to simplify reality so that it fits their world view. Stupid people
> attempt to force that simplified reality onto others. You can either
> play their game, attempting to get them to understand reality is often
> more complicated than we'd like, or route around them. Or you can post
> to NANOG... :-)

The root of the argument I see in this entire thread is the assumption that
'what we have for IPv4 has *always* been there'. There is lots of finger
pointing at the IETF for failure to define 15 years ago, what we have
evolved as the every-day assumptions about the IPv4 network of today. SLAAC
was presented specifically to deal with the DHCP failure modes of the time,
and the very real possibility that DHCP might not make it as a technology
that operators would want to deploy. While lots of evolution happened in the
DHCP space to deal with changing operational requirements, it is still a
complex approach (which may be why it is favored by those that like to
maintain a high salary). To be fair, there were failures in the IETF, as
the SLAAC and DCHP sides couldn't get out of each other's way; so now
instead of having 2 independent models for provisioning, we have 2
interdependent models. RFC 5006 is one step at breaking that
interdependence, and more are needed on the DHCPv6 side, yet these steps
can't happen if people sit in the corner and do the 'they won't listen to
me' routine.

For those that insist that DHCP is 'the only way to know who is using an
address', have you considered dDNS? Oh wait, that moves the trust point to a
different service that in the enterprise is typically run by the host admin,
not the network admin, or in the SP case crosses the trust boundary in the
wrong direction ... my bad. Seriously, there are ways to figure this out, as
Ron Broersma pointed out on Monday. I am not arguing for one model over the
other, as they each have their benefits and trade-offs. The real issue here
is that some people are so locked into one approach that they refuse to even
consider that there might be an alternative way to achieve the same goal, or
that the actual goal will change over time in the face of external
requirements.

IPv4 continues to be a work-in-progress 30 years later, and IPv6 will be no
different. The fact that there is not functional parity between the
operational aspects is due to operators insisting until very recently that
'the only thing that matters is IPv4'. It should not be a surprise that IPv4
is where the majority of the work in the IETF happened. Despite my attempts
to get the IETF to stop wasting effort on what is clearly a dead-end, this
is still true today. As drc points out, you can continue to post complaints
on the nanog list, or if you want real change make sure your vendors get a
clear message about IPv6 being the priority, then make your point on the
appropriate IETF WG list.

At the end of the day, the way networks are operated today is not the way
they will be operated in 5 years, just as it is not the same as they way
they were operated 5 year ago. Asserting a snap-shot perspective about
'requirements' has its place, but everyone needs to recognize that this is
an evolving environment. Changing the base protocol version is just one more
step on that evolutionary path.

Tony

rps at maine

Oct 22, 2009, 12:42 PM

Post #91 of 151 (730 views)
Permalink

Re: {SPAM?} Re: IPv6 Deployment for the LAN [In reply to]

Sorry, not buying it.

The solution here, and one that is already being worked on by vendors,
is RA gaurd, not changing DHCPv6 in an effort to bypass RA.

What your proposing as a solution isn't much of a solution at all but
just a (seemingly) lesser problem.

On Thu, Oct 22, 2009 at 3:29 PM, Leo Bicknell <bicknell [at] ufp> wrote:
> In a message written on Thu, Oct 22, 2009 at 03:23:13PM -0400, Ray Soucy wrote:
>> If the argument against RA being used to provide gateway information
>> is "rogue RA," then announcing gateway information though the use of
>> DHCPv6 doesn't solve anything. �Sure you'll get around rogue RA, but
>> you'll still have to deal with rogue DHCPv6. �So what is gained?
>
> It's a huge difference, and any conference network shows it.
>
> Let's assume 400 people come into a room, get up and working (with
> DHCPv4, and IPv6 RA's).
>
> Someone now introduces a rogue IPv4 server. �Who breaks? �Anyone who
> requests a new lease. �That is 400 people keep working just fine.
>
> Now, someone introduces a roge RA. �Who breaks? �All 400 users are
> instantly down.
>
> More importantly, there is another class of misconfigured device. �I
> plugged in a Cisco router to download new code to it on our office
> network. �It had a DHCP forward statement, and IPv6. �It was from
> another site.
>
> The DHCP forward didn't work, it pointed to something non-existant that
> also was never configured for the local subnet. �There was zero chance
> of IPv4 interfearance.
>
> The IPv6 network picked up the RA to a router with no routes though, and
> so simply plugging in the old router took down the entire office
> network.
>
> The operational threats of a DHCP based network and a RA based network
> are quite different. �Try it on your own network.
>
> --
> � � � Leo Bicknell - bicknell [at] ufp - CCIE 3440
> � � � �PGP keys at http://www.ufp.org/~bicknell/
>

--

Ray Soucy
Communications Specialist

+1 (207) 561-3526

Communications and Network Services

University of Maine System
http://www.maine.edu/

bicknell at ufp

Oct 22, 2009, 12:50 PM

Post #92 of 151 (730 views)
Permalink

Re: {SPAM?} Re: IPv6 Deployment for the LAN [In reply to]

In a message written on Thu, Oct 22, 2009 at 03:42:19PM -0400, Ray Soucy wrote:
> The solution here, and one that is already being worked on by vendors,
> is RA gaurd, not changing DHCPv6 in an effort to bypass RA.

Port based solutions don't work well on wireless networks and other
mediums.

--
Leo Bicknell - bicknell [at] ufp - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

rps at maine

Oct 22, 2009, 12:57 PM

Post #93 of 151 (730 views)
Permalink

Re: {SPAM?} Re: IPv6 Deployment for the LAN [In reply to]

Really. How do we deal with rouge DHCP on the wireless LAN, obviously
this is such a complex issue that we couldn't possibly have a solution
that could be applied to RA.

On Thu, Oct 22, 2009 at 3:50 PM, Leo Bicknell <bicknell [at] ufp> wrote:
> In a message written on Thu, Oct 22, 2009 at 03:42:19PM -0400, Ray Soucy wrote:
>> The solution here, and one that is already being worked on by vendors,
>> is RA gaurd, not changing DHCPv6 in an effort to bypass RA.
>
> Port based solutions don't work well on wireless networks and other
> mediums.
>
> --
> � � � Leo Bicknell - bicknell [at] ufp - CCIE 3440
> � � � �PGP keys at http://www.ufp.org/~bicknell/
>

--

Ray Soucy
Communications Specialist

+1 (207) 561-3526

Communications and Network Services

University of Maine System
http://www.maine.edu/

cra at WPI

Oct 22, 2009, 1:06 PM

Post #94 of 151 (730 views)
Permalink

Re: {SPAM?} Re: IPv6 Deployment for the LAN [In reply to]

On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote:
> Really. How do we deal with rouge DHCP on the wireless LAN, obviously
> this is such a complex issue that we couldn't possibly have a solution
> that could be applied to RA.

Rogue DHCP doesn't immedately take down the entire subnet of machines
with existing DHCP leases. It generally only affects new machines
trying to get a lease, or RENEWing machines. The impact of a rogue RA
is to immediately break connectivity for every machine on the subnet.
Differing impacts leads to different risk assessments of which
protocol to use.

Regardless, modern wireless deployments use central controllers or
smart APs that can filter DHCP. They could be extended to filter RA
as well.

And this whole point is rather moot because we have RAs and must deal
with them. It is too late to get rid of the RA behavior of clients.
Even if you don't want to use RAs, your hosts are going to still
listen to them which means a Rogue RA is going to take down your
network. We have this problem even on IPv4-only subnets, where a
Rogue RA (usually a Windows box with routing turned on) breaks
connectivity to dual-stack servers for machines on that subnet. Since
the hosts prefer native IPv6 connectivity over IPv4, the hosts end up
preferring the Rogue RA as the route towards the dual-stack server.

We really just need to bug our vendors to implement Rogue RA
protection for wired and wireless ASAP, wherever we are in our
deployment of IPv6.

drc at virtualized

Oct 22, 2009, 1:24 PM

Post #95 of 151 (730 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

Tony,

On Oct 22, 2009, at 12:41 PM, Tony Hain wrote:
> The root of the argument I see in this entire thread is the assumption that
> 'what we have for IPv4 has *always* been there'.

Well, no. My reading is "what we have for IPv4 works, scales well, we're accustomed to it, and our provisioning systems are all built around it'.

> There is lots of finger
> pointing at the IETF for failure to define 15 years ago, what we have
> evolved as the every-day assumptions about the IPv4 network of today.

Well, no. My reading is that there is finger pointing at the IETF for ignoring and/or denying what network operators are specifying.

> The real issue here
> is that some people are so locked into one approach that they refuse to even
> consider that there might be an alternative way to achieve the same goal, or
> that the actual goal will change over time in the face of external
> requirements.

Actually, I think the issue is that there are folks who are running real, live businesses who don't really have the time (or interest) to experiment with alternative ways of doing things. They're getting pressure to deploy new stuff and are looking for technologies that are the quickest, easiest, requires the least retraining, retooling, redeployment, etc. They then get folks (most of which do not run real, live non-trivial networks) who say "use this new shiny toy!" and block efforts to hack the existing tools.

It's that last bit that's the problem.

But then again, I'm just guessing since I don't run a real, live non-trivial network...

Regards,
-drc

owen at delong

Oct 22, 2009, 1:29 PM

Post #96 of 151 (732 views)
Permalink

Re: {SPAM?} Re: IPv6 Deployment for the LAN [In reply to]

On Oct 22, 2009, at 12:23 PM, Ray Soucy wrote:

>> This to me is one of the least credible claims of the RA/SLAAC crowd.
>> On the one hand we have carriers around the world with millions and
>> millions of customers getting default routes and other config through
>> DHCPv4 every day. And most of the time it actually works very well!
>>
>> On the other hand we have RA/SLAAC with a vastly smaller customer
>> base, vastly less real life testing - but which is still claimed to
>> be so much better that DHCPv6 is not *allowed* to get a default route
>> option.
>
> If the argument against RA being used to provide gateway information
> is "rogue RA," then announcing gateway information though the use of
> DHCPv6 doesn't solve anything. Sure you'll get around rogue RA, but
> you'll still have to deal with rogue DHCPv6. So what is gained?
>
Apparently you missed the entire message he responded to about the
number of things specified by DHCP and the differences between the
groups in control of the routers vs control of the hosts/servers and the
actual administrative groups in charge of each?

> I guess I'm not really seeing the case here. Are people really making
> use of DHCP to provide hosts on the same network with different
> default gateway information? If so, why?
>
Yes. A number of different application and business requirements. Some
I can go into easily (load balancing among different routers, routers
owned
by different departments, etc.), some are proprietary to my clients
and I can't
give enough details without violating NDA.

> Or is it that you want IPv6 to be a 128-bit version of IPv4? RA is a
> good idea and it works. You can add options to DHCPv6, but I don't
> see many vendors implementing default gateway support unless you can
> make a real case for it.
>
The assignment of gateway information to the host belongs in the hands
of the
systems administrators and not in the hands of the people running the
switches and routers in many organizations.

With router information assigned through DHCP, this is preserved.
With it
being assigned by the router, it is not, and, in fact, the case. With
DHCPv6
unable to assign router information you lose that administrative
boundary
and take away a systems administrators control over their hosts and hand
it to the networking group.

> My fear is that your goal is to do away with RA completely and turn to
> DHCPv6 for all configuration. RA is actually quite nice. You really
> need to stop fighting it, because it's not going away.
>
Not at all. People are not saying RA has to go away. They are saying
we
need the option of DHCPv6 doing the job where we do not feel that RA is
the correct tool.

More tools are good. Replacing one tool that works today with a new
tool
that is arguably inferior in many real world cases, on the other hand,
is
not so good.

Owen

rps at maine

Oct 22, 2009, 1:32 PM

Post #97 of 151 (731 views)
Permalink

Re: {SPAM?} Re: IPv6 Deployment for the LAN [In reply to]

Correct.

Not sure if you got the sarcasm in that last reply...

As far as I'm concerned, a rogue is a rogue. Knowing about it the
instant it happens might even be better than slowly coming to the
realization that you're dealing with one. The point is that we need
to address rogues regardless of their type, not move from RA to DHCPv6
because the impact of a rogue is slower to disrupt service.

On Thu, Oct 22, 2009 at 4:06 PM, Chuck Anderson <cra [at] wpi> wrote:
> On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote:
>> Really. �How do we deal with rouge DHCP on the wireless LAN, obviously
>> this is such a complex issue that we couldn't possibly have a solution
>> that could be applied to RA.
>
> Rogue DHCP doesn't immedately take down the entire subnet of machines
> with existing DHCP leases. �It generally only affects new machines
> trying to get a lease, or RENEWing machines. �The impact of a rogue RA
> is to immediately break connectivity for every machine on the subnet.
> Differing impacts leads to different risk assessments of which
> protocol to use.
>
> Regardless, modern wireless deployments use central controllers or
> smart APs that can filter DHCP. �They could be extended to filter RA
> as well.
>
> And this whole point is rather moot because we have RAs and must deal
> with them. �It is too late to get rid of the RA behavior of clients.
> Even if you don't want to use RAs, your hosts are going to still
> listen to them which means a Rogue RA is going to take down your
> network. �We have this problem even on IPv4-only subnets, where a
> Rogue RA (usually a Windows box with routing turned on) breaks
> connectivity to dual-stack servers for machines on that subnet. �Since
> the hosts prefer native IPv6 connectivity over IPv4, the hosts end up
> preferring the Rogue RA as the route towards the dual-stack server.
>
> We really just need to bug our vendors to implement Rogue RA
> protection for wired and wireless ASAP, wherever we are in our
> deployment of IPv6.
>
>

--

Ray Soucy
Communications Specialist

+1 (207) 561-3526

Communications and Network Services

University of Maine System
http://www.maine.edu/

dwhite at olp

Oct 22, 2009, 1:33 PM

Post #98 of 151 (730 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On 22/10/09�16:06�-0400, Chuck Anderson wrote:
>On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote:
>> Really. How do we deal with rouge DHCP on the wireless LAN, obviously
>> this is such a complex issue that we couldn't possibly have a solution
>> that could be applied to RA.
>
>Rogue DHCP doesn't immedately take down the entire subnet of machines
>with existing DHCP leases. It generally only affects new machines
>trying to get a lease, or RENEWing machines. The impact of a rogue RA
>is to immediately break connectivity for every machine on the subnet.
>Differing impacts leads to different risk assessments of which
>protocol to use.

That breaks both ways. You could do maintenance in the middle of the night
and break DHCP in unexpected ways (which I've seen happen) and then you
have the problem of manually rebooting (or renewing) all those devices the
next morning when you notice they're not working.

>We really just need to bug our vendors to implement Rogue RA
>protection for wired and wireless ASAP, wherever we are in our
>deployment of IPv6.

VLAN per subscriber fixes this. It's not really appropriate everywhere, but
it's a nice solution for wireless and ISP scenarios.

--
Dan White

nanog at 85d5b20a518b8f6864949bd940457dc124746ddc

Oct 22, 2009, 1:42 PM

Post #99 of 151 (731 views)
Permalink

Re: IPv6 Deployment for the LAN [In reply to]

On Thu, 22 Oct 2009 21:20:11 +1100
Karl Auer <kauer [at] biplane> wrote:

> On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote:
> > If, on the other hand, the REAL desire is to have a DHCP server break
> > the tie in the selection between several routers that advertise their
> > presence, that wouldn't be unreasonable.
>
> The RA contains a preference level... maybe that doesn't cut it if
> multiple routers are sending the same preference level, but presumably
> that would not happen in a well-tended network.
>

IPv6 Subnets/VLANs are pretty cheap, maybe if people are having this
issue, that's a sign they need to divide their hosts into more
subnets/VLANs.

More broadly, it seems the argument is where to put networking
operational policy - in the network (via e.g. engineered topology), or
on the hosts. I think there is value in putting it in the network,
because it avoids having to change host located policy when the
network policy changes.

> In any case, anywhere this is actually of vital importance, a routing
> protocol would be in use.
>
> Using the DHCP protocol to deliver information - about anything really -
> is what it's *for*. That said, making clients depend utterly on the
> presence of a working DHCP server for basic connectivity seems like a
> backward step. Of course, different people have different ideas about
> what constitutes "basic" connectivity.
>
> > Stop trying to break the internet and I'll treat you like an adult.
>
> Whoa! Tell you what, how about if I break it, and you get to choose
> which piece you keep? [.Bash, bash, thud. Ugh. Hm. It's tougher than it
> looks!]
>
> :-)
>
> Regards, K.
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Karl Auer (kauer [at] biplane) +61-2-64957160 (h)
> http://www.biplane.com.au/~kauer/ +61-428-957160 (mob)
>
> GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
>

thegameiam at yahoo

Oct 22, 2009, 1:49 PM

Post #100 of 151 (731 views)
Permalink

Re: {SPAM?} Re: IPv6 Deployment for the LAN [In reply to]

---- Original Message ----
From: Ray Soucy <rps [at] maine>

>Or is it that you want IPv6 to be a 128-bit version of IPv4?�

Yes, this is in fact exactly what the network operators keep saying.�

>RA is a
>good idea and it works.� You can add options to DHCPv6, but I don't
>see many vendors implementing default gateway support unless you can
>make a real case for it.
>My fear is that your goal is to do away with RA completely and turn to
>DHCPv6 for all configuration.� RA is actually quite nice.� You really
>need to stop fighting it, because it's not going away.

RA may be quite nice for some cases.� However, several examples over this thread alone have been provided about some other cases where it is something other than nice.�

DHCPv4 is not a perfect protocol, but it's widely deployed and understood.� It also is a one-stop-shop for centralized host configuration.� IPv6 does not currently have a similar one-stop-shop protocol, and this is a major gap in functionality.��There are a bunch of very large providers and enterprises which number their DHCP-managed end-sites in the hundreds of thousands or millions.� The inability to provide the same centralized configuration management should not be considered a feature.

David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com

1 2 3 4 5 6 7

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads