v6 subnet size for DSL & leased line customers

Mailman List Mirror (Read Only)
1

> The primary reasons I see for separate networks on v6 would include
> firewall policy (DMZ, separate departmental networks, etc)...

This is certainly one reason for such things.

Really, in most "small business" networks I've seen, it's by far the main
one if we want to be honest about it. The use of multiple networks to
increase performance, for example, is something you can design around
differently, and modern hardware supports things like LAG without having
to get into the realm of unimaginably expensive hardware. Even if you do
end up putting a quad port ethernet into a server with v6, the sizes of
the allocations we're discussing would allow you 64 completely separate
"workgroups" with their own server at the /56 allocation size (64 * 4 =
256).

> And I'm having some trouble envisioning a residential end user that
> honestly has a need for 256 networks with sufficiently differently
> policies. Or that a firewall device can't reasonably deal with those
> policies even on a single network, since you mainly need to protect
> devices from external access.

Perhaps this is a lack of imagination.

Imagine that your ethernet->bluetooth gateway wants to treat the
bluetooth
and ethernet segments as separate routed segments.

That /is/ a lack of imagination. :wink: Or, at least, reaching pretty far.
The history of these sorts of devices has been, to date, one of trying to
keep network configuration simple enough that an average user can use
them. That implies a default mode of bridging will be available.

Now, imagine that some of your bluetooth connected devices have reasons
to have some topology behind them... For example, you have a master
appliance control center which connects via Bluetooth to your network,
but, uses a different household control bus network to talk to various
appliances. For security reasons, you've decided not to have your
kitchen appliances be able to talk to your media devices (Who wants
a virus in some downloaded movie to be able to change the temperature
in your refrigerator?).

Yes, and? You're saying there are no access controls at the gateway
level? I'm not entirely sure that I care for the idea of making people
route things at the IP level just so they can protect their fridge from
their DVD.

> I keep coming to the conclusion that an end-user can be made to work
> on
> a /64, even though a /56 is probably a better choice. I can't find
> the
> rationale from the end-user's side to allocate a /48. I can maybe see
> it if you want to justify it from the provider's side, the cost of
> dealing
> with multiple prefix sizes.

I can easily envision the need for more than a /64 in the average home
within short order.

You should probably correct that from "need" to "want." There is nothing
preventing the deployment of all of the below on a single /64, it would
simply mean that there would be a market for smart firewalling switches
that could isolate devices by address or range, rather than having smart
firewalling routers that could isolate devices by subnet.

If nothing else, the average home will probably
want to be able to accommodate:
  Guest network
  Home wired network
  Wireless network(s)
  Bluetooth segment(s)
  Media network
  Appliance Control netowrk
  Lighting Control network
  etc.

However, I agree that in any vision I can come up with today, the need
for more than 256 is beyond my current imagination.

Again, I think this comes down to a matter of how configuration is going
to be handled. I suspect that we're not going to see a substantial
increase in sophistication on the part of end users. I /believe/ that
this will likely mean that device manufacturers will be building devices
that don't rely on routing for IPv6, since if I go on down to my employer's
network and plug in a bluetooth gateway, there's really no guarantee that
I'm going to be able to get my employer's network to magically route a
network at my gateway, but it's pretty obvious that my device can play the
role of a bridge.

If we have significant customer-side routing of IPv6, then there's going
to need to be some way to manage that. I guess that's RIPv6/ng. :slight_smile:

More likely-seeming to me, would be that a provider might be willing to
provide a CPE device that had 4, 8, or even 16 jacks on it - a mini-router
with a separate /64 on each port, less "magic" to be figured out by the end
user.

This leaves the question of how much you want to trust your ISP's CPE for
firewalling policy ... among other things.

I think it makes sense to assign as follows:

/64 for the average current home user.
/56 for any home user that wants more than one subnet
/48 for any home user that can show need.

I'd say skip the /64 and /48. Don't do the /64, as future-proofing. A
/48 is just something I cannot see need for, given the number of addresses
available as a /56, unless the "home user" is actually providing
connectivity to a bunch of his nearby friends and neighbors.

Having fewer options is going to be easier for the ISP, I suspect.

... JG

2

The primary reasons I see for separate networks on v6 would include
firewall policy (DMZ, separate departmental networks, etc)...

This is certainly one reason for such things.

Really, in most "small business" networks I've seen, it's by far the main
one if we want to be honest about it. The use of multiple networks to
increase performance, for example, is something you can design around
differently, and modern hardware supports things like LAG without having
to get into the realm of unimaginably expensive hardware. Even if you do
end up putting a quad port ethernet into a server with v6, the sizes of
the allocations we're discussing would allow you 64 completely separate
"workgroups" with their own server at the /56 allocation size (64 * 4 =
256).

Agreed. In fact, in any network large enough to matter, most modern
hardware forwards L2 and L3 at the same speed, so, there's essentially
no performance barrier.

OTOH, in many business netwoks I've seen, there is reason to segment
things into administrative boundaries, boundaries that result from media
conversion creating routed separation of segments, and, other topology
meets physical limitation issues. I find these to be at least as common
as the separation between Internal/External/DMZ.

And I'm having some trouble envisioning a residential end user that
honestly has a need for 256 networks with sufficiently differently
policies. Or that a firewall device can't reasonably deal with those
policies even on a single network, since you mainly need to protect
devices from external access.

Perhaps this is a lack of imagination.

Imagine that your ethernet->bluetooth gateway wants to treat the
bluetooth
and ethernet segments as separate routed segments.

That /is/ a lack of imagination. :wink: Or, at least, reaching pretty far.
The history of these sorts of devices has been, to date, one of trying to
keep network configuration simple enough that an average user can use
them. That implies a default mode of bridging will be available.

You are ignoring the reality of the difference between IPv4 and IPv6.

With DHCP6 prefix delegation, creating a hierarchical routed topology
becomes as simple (from the end user perspective) as the bridged
topology today, and, requires a lot less thinking ability on the device.
Especially when you consider the possibility of many such topologies
evolving in a situation that could create a loop and the fact that most
such existing devices implement bridging without spanning tree.

Now, imagine that some of your bluetooth connected devices have reasons
to have some topology behind them... For example, you have a master
appliance control center which connects via Bluetooth to your network,
but, uses a different household control bus network to talk to various
appliances. For security reasons, you've decided not to have your
kitchen appliances be able to talk to your media devices (Who wants
a virus in some downloaded movie to be able to change the temperature
in your refrigerator?).

Yes, and? You're saying there are no access controls at the gateway
level? I'm not entirely sure that I care for the idea of making people
route things at the IP level just so they can protect their fridge from
their DVD.

I'm saying that bridges tend not to have access controls or at least not
adequate access controls except in a few (l2 firewall oddities like
Netscreen/PIX in Bridge mode) exceptional cases. The point here
is that in IPv6, you aren't "making people route things", the routing
topology will mostly handle itself automatically, although, people
may wish to intervene to design the security policy or at least have
the ability to modify it from the default.

You are trying to apply strictly IPv4 thinking to IPv6, and, there are
some reasons that a significant paradigm shift is required.

I keep coming to the conclusion that an end-user can be made to work
on
a /64, even though a /56 is probably a better choice. I can't find
the
rationale from the end-user's side to allocate a /48. I can maybe see
it if you want to justify it from the provider's side, the cost of
dealing
with multiple prefix sizes.

I can easily envision the need for more than a /64 in the average home
within short order.

You should probably correct that from "need" to "want." There is nothing
preventing the deployment of all of the below on a single /64, it would
simply mean that there would be a market for smart firewalling switches
that could isolate devices by address or range, rather than having smart
firewalling routers that could isolate devices by subnet.

We will agree to disagree on this. Enforcing security policy within
a subnet is ugly at best and unreliable at worst. It makes troubleshooting
harder. It makes security policy design more complex. It causes many
many more problems than it solves in my opinion.

If nothing else, the average home will probably
want to be able to accommodate:
  Guest network
  Home wired network
  Wireless network(s)
  Bluetooth segment(s)
  Media network
  Appliance Control netowrk
  Lighting Control network
  etc.

However, I agree that in any vision I can come up with today, the need
for more than 256 is beyond my current imagination.

Again, I think this comes down to a matter of how configuration is going
to be handled. I suspect that we're not going to see a substantial
increase in sophistication on the part of end users. I /believe/ that
this will likely mean that device manufacturers will be building devices
that don't rely on routing for IPv6, since if I go on down to my employer's
network and plug in a bluetooth gateway, there's really no guarantee that
I'm going to be able to get my employer's network to magically route a
network at my gateway, but it's pretty obvious that my device can play the
role of a bridge.

Actually, there is some guarantee that, in IPv6, you'll be able to do that,
or, you will know that you could not. You will make a DHCP6 request
for a prefix delegation, and, you will receive it or be told no.

Most likely, that is how most such v6 gateways will function.

I think that bridges are less likely to be the norm in IPv6.

If we have significant customer-side routing of IPv6, then there's going
to need to be some way to manage that. I guess that's RIPv6/ng. :slight_smile:

Nope... DHCPv6 prefix delegation and Router discovery.

More likely-seeming to me, would be that a provider might be willing to
provide a CPE device that had 4, 8, or even 16 jacks on it - a mini-router
with a separate /64 on each port, less "magic" to be figured out by the end
user.

Sure. And likely, the /64s on each port will be assigned via DHCPv6 from
the upstream segment.

This leaves the question of how much you want to trust your ISP's CPE for
firewalling policy ... among other things.

LoL... Trust my ISPs CPE? Not if they control it.

I think it makes sense to assign as follows:

/64 for the average current home user.
/56 for any home user that wants more than one subnet
/48 for any home user that can show need.

I'd say skip the /64 and /48. Don't do the /64, as future-proofing. A
/48 is just something I cannot see need for, given the number of addresses
available as a /56, unless the "home user" is actually providing
connectivity to a bunch of his nearby friends and neighbors.

I have no objection to skipping the /64, but, I don't think you'll get much
traction with that with most of the larger ISPs (think AOL, Comcast, etc.)
as I think they will want to charge more for a topology-supporting service
than a single subnet if current business models are an example of their
plans for the future.

Having fewer options is going to be easier for the ISP, I suspect.

Nope. Each ISP can choose to offer whatever subset of these options they consider
easiest. Having fewer options for them to choose from isn't easier for them, it's putting
them in a straight-jacket, which, from my experience as an active participant in the
ARIN policy process is usually not appreciated by them.

Owen

3

the "but what if they want the toaster on a separate subnet from the
blender" gives a new depth to 'reaching.' the one case i can think of
for firewalling/routing within the home is to keep the bathroom scale
from locking the fridge.

and if you can't make a reasonable case for it today, then yagni. leave
boiling the ocean to the experts at the tvtf.

randy

4

Joe Greco wrote:

I'd say skip the /64 and /48. Don't do the /64, as future-proofing. A
/48 is just something I cannot see need for, given the number of addresses
available as a /56, unless the "home user" is actually providing
connectivity to a bunch of his nearby friends and neighbors.

Having fewer options is going to be easier for the ISP, I suspect.
  

Not just the ISP, but the home user, and the designers of the devices for the home. As you point out, device configuration in the home needs to be as simple as possible. It would be nice if designers of new networked home devices (particularly those that that would like to use media types which might not be readily bridged to other common media types) could have some reasonable assurance up front that they have the option of an IPv6 subnet in the home to use. This would then be one less thing to try and automatically discover, ask the user to configure information about, develop a workaround for, etc. Less options is a very good thing here, and rampant /64s could well paint the device manufacturers into a corner on what tools IPv6 gives them to take advantage of.

- Mark

5

can you expound some on the last part of this? the 'rampant /64's..'
part? Since auto-conf pretty much requires the LAN to be /64 sized and
if you believe more than 1 subnet would be of use to the
end-user/residence then there are only a few options left, eh? It
seems that the ppp-o-e sorts of connections could pass out this
information and make the lives of equipment/user easier, what sort of
options were you envisioning? (or what were you hoping to avoid?)

I ask because I'm fairly certain the operator and standards-body folks
both would be curious about a vendor's (or vendor-ish-person's view)
view on this issue, I just don't think a rational answer is
forthcoming from the 'user' community on this quite yet :frowning:

-Chris

6

Randy Bush wrote:

the "but what if they want the toaster on a separate subnet from the
blender" gives a new depth to 'reaching.' the one case i can think of
for firewalling/routing within the home is to keep the bathroom scale
from locking the fridge.

and if you can't make a reasonable case for it today, then yagni. leave
boiling the ocean to the experts at the tvtf.

If ipv6 subnetting is going to be hosed up at this point it's going to
be done by people deploying it.

7

Joel Jaeggli wrote:

Randy Bush wrote:

the "but what if they want the toaster on a separate subnet from the
blender" gives a new depth to 'reaching.' the one case i can think of
for firewalling/routing within the home is to keep the bathroom scale
from locking the fridge.

If ipv6 subnetting is going to be hosed up at this point it's going to
be done by people deploying it.

unfortunately, 'hosed up' only seems to be understood some years out.

smb's point is apt, we always end up too small.

but i still have a very hard time understanding what we are gonna do
with more than a /56 to a consumer connection.

and if i start to go to the left of a /56, where do i stop? there is no
obvious detent on the knob.

randy

8

Randy Bush wrote:

Joel Jaeggli wrote:

Randy Bush wrote:

the "but what if they want the toaster on a separate subnet from the
blender" gives a new depth to 'reaching.' the one case i can think of
for firewalling/routing within the home is to keep the bathroom scale
from locking the fridge.

If ipv6 subnetting is going to be hosed up at this point it's going to
be done by people deploying it.

unfortunately, 'hosed up' only seems to be understood some years out.

smb's point is apt, we always end up too small.

but i still have a very hard time understanding what we are gonna do
with more than a /56 to a consumer connection.

Leave enough address space for pd to occur? We know that if I hand you
the end-user a /64 that the first device that you connect to the network
(wireless/ethernet router) will nat because it wants a l3 boundary
between the outside and the inside for v6 just like it has for v4. If
that device, when it boots and requests pd receives a /64, cool... but
what does it do when some device downstream from it asks for address space?

So is a /64 ok for an end customer? No because it doesn't meet the
criterion of a location where one and only one subnet will be needed.
Does it need a whole /48? Probably not.

What you need in your provisioning system and how you structure
address-space usage for the benefit of your IGP is that downstream
devices need to be able to request and receive blocks of a size
commiserate with their needs without increasing the footprint of your
routing table.

and if i start to go to the left of a /56, where do i stop? there is no
obvious detent on the knob.

There is a huge detent at /48, but there's a certain amount of guidance
that can only be derived from operational experience. It's not clear to
me why /56 would be unacceptable, particularly if you're delegating them
to a device that already has a /64. Are one's customers attached via
point-to-point links, or do they sit on shared broadcast domain where
their cpe is receiving a /128 and requesting pd from the outset?

When someone plugs an apple airport into a segment of the corporate lan
should it be be able to request pd under those circumstances as well?
how is that case different than plugging it in on a residential connection?

These are issues providers can and should grapple with. Much as
assigning a /32 to a residential customer vs /30 or /28 is a business
decision. In many if not most cases we don't currently provide as many
v4 addresses as there are devices within the customer premises. Enough
addresses isn't going to be an issue in v6, The dynamic creation of
topology that was automatically and at least in one direction
transparently created by restricted-cone nats is obviously something new.

9

There is a huge detent at /48

other than the perennial operational pontification from on high by the
gods of the ietf (brought to us by the folk who brought us the wonderful
TLA, NLA, etc. classfulness++), could you elucidate?

randy

10

Randy Bush wrote:

There is a huge detent at /48

other than the perennial operational pontification from on high by the
gods of the ietf (brought to us by the folk who brought us the wonderful
TLA, NLA, etc. classfulness++), could you elucidate?

From one angle, last time I looked, the RIRs were converging on that as

acceptable minimum for a single PI allocation.

/48 is a large enough block that single site however you choose to
define that, is not going to have to renumber out of it due to inability
to subnet.

If you mean there's no detent between /48 and /56 wouldn't you a
wholesale operator determine that based on the need and guidance from
your rir? We do not in ipv4 land just hand out /19s and /20s to
customers until we can go back to arin for another /12...

If you're asking why ipng doesn't incorporate the lessons of cidr
(they're both responses to the same problem), then you tell me, you were
there and I was in high-schol.

11

There is a huge detent at /48

other than the perennial operational pontification from on high by the
gods of the ietf (brought to us by the folk who brought us the wonderful
TLA, NLA, etc. classfulness++), could you elucidate?

From one angle, last time I looked, the RIRs were converging on that as
acceptable minimum for a single PI allocation.

look again

/48 is a large enough block that single site however you choose to
define that, is not going to have to renumber out of it due to inability
to subnet.

one: as smb says, no amount turns out to be enough in the long run
two: my point is that, for the reasonably forseable future, hard to
     see need for more than 256 routing segments needed by an end
     consumer site

If you mean there's no detent between /48 and /56 wouldn't you a
wholesale operator determine that based on the need and guidance from
your rir?

you said there was a huge detent at /48. i am trying to see how you got
there. excuse my density, but i still can not.

If you're asking why ipng doesn't incorporate the lessons of cidr
(they're both responses to the same problem), then you tell me, you were
there and I was in high-school.

expedience and politics ruled over prudent engineering. classic tvtf.

randy

12

What about the "wan" side of that connection? I want the customer to only source traffic from the /56 being assigned and I don't want ISP router to have any IPs in that space. Does IPv6 capable CPEs have the possibility to source packets from local network (received via pd) and only have FE80: IP for upstream routing which is never used as an SRC address for communication with the outside world (apart from upstream router)?

If not, is this something that we should ask the CPE vendors for? It would be extremely nice for CoPP etc for ISP routers to have no IP in customer space, and CPEs to have no IP in ISP link-network space. Would make for very effective infrastructure ACLs.

13

If you mean there's no detent between /48 and /56

What does "no detent between..." mean?

If you're asking why ipng doesn't incorporate the lessons of cidr

What lessons would that be?

Does IPv6 capable CPEs have the possibility to source packets from local network (received via pd) and only have FE80: IP for upstream routing which is never used as an SRC address for communication with the outside world (apart from upstream router)?

IPv6 routing protocols allow this, yes. I can't remember if I tried it with Cisco's prefix delegation but I'm fairly confident it would work for that, too.

The dibbler seemed to be rather complete DHCPv6 implementation. I think default gateway and prefix length distribution via DHCPv6 will be quite problematical any many situation. There plenty of organisation who has a dedicated team/person for network management (routers, switches etc.), while another team/person for system management (dhcp, servers etc.). So configuring DHCPv6 requires cooperation which takes time, but users are complaining....

Hm, I haven't heard that argument used against DHCPv6. (On principle, I'm against doing something that's technically suboptimal because it's easier organizationally, though.)

Having a default router in DHCPv6 would be a mistake because if the DHCPv6 server isn't also the default router, this introduces an opportunity for failures that isn't there with router advertisements.

I've heard people argue that prefixes should be in RAs for much the same reason and therefore it's a good thing that DHCPv6 doesn't know about the prefix _length_ but that doesn't convince me: if you give someone an address, you impliccitly also give them a prefix, so it makes no sense to withhold the prefix length and require another protocol to learn this information.

so, what problems are there with dhcpv6 that differ from those we have
experienced with dchpv4? what would be good to know before trying to
deploy it?

The difference is that for IPv4, it's DHCP or manual configuration. With IPv6, you also have stateless autoconfig using router advertisements. So it's no so much what DHCPv6 does that IPv4 DHCP doesn't do, but what you can do without DHCPv6 that you couldn't do without DHCP in IPv4. In small IPv4 networks the DHCP server runs on the router so there is fate sharing, but this doesn't work well if there is more than one router. In that case you'll soon be running a DHCP server that's separate from the routers and thus opening up a new failure mode. With RAs hosts get the same address regardless of which router they happen to talk to so it's a lot more robust than either the single router model or the separate DHCP server model.

do organizations you know prefer autoconf or dhcpv6? and why?

What I hear is that enterprise admins want DHCPv6 because they want to have control. Me, I want to run a DHCPv6-free network because RAs give me what I want and more protocols just means more headaches.

Second, we currently have two mechanisms to configure IPv6 hosts with
an address: router advertisements and DHCPv6. The former has been
implemented in ALL IPv6 stacks but doesn't work if your subnet isn't
a /64.

But the protocols don't imply or require this. All of the messages
used in stateless autoconfig will behave as expected with longer prefix
lengths. So it seems that because the interface identifier has to be
64-bits, stateless autoconfig is unnecessarily crippled.

The idea is that your interface identifier that you create locally from a MAC address is unique. With less than 46 bits that's not going to happen. Unforatunately, the 17 or 18 bits that you don't need for this are in the middle. But at some point in the future we can revist this and free up 16 bits so anyone with a /64 can create 65535 fresh subnets out of nothing, which is good insurance against possible bad address allocation policies.

Note that there's duplicate address detection but that only _detects_ the problem and doesn't fix it if there are duplicate addresses.

14

> do organizations you know prefer autoconf or dhcpv6? and why?

What I hear is that enterprise admins want DHCPv6 because they want to
have control. Me, I want to run a DHCPv6-free network because RAs give
me what I want and more protocols just means more headaches.

I would much prefer DHCPv6 to work "just like DHCPv4" - which means
that the great bulk of our customers are configured with an unnumbered
interface on a BRAS, and all the relevant IP configuration is on the
DHCP server. The key here is avoidance of customer-specific config on
the BRAS.

It's beginning to sound like IPv6 is going to be considerably more
complex than IPv4 here - which is certainly going to slow its uptake...

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

15

> do organizations you know prefer autoconf or dhcpv6? and why?

What I hear is that enterprise admins want DHCPv6 because they want to
have control. Me, I want to run a DHCPv6-free network because RAs give

not control, but 'the same functionality and capabilities as exist
today' (which is atleast resolver definitions, default-gw,
ip-addressing, equipment/asset tracking... more)

me what I want and more protocols just means more headaches.

and trying to keep 50k machines updated with proper resolvers (in the
simplest example) is easier with RA than DHCP how?

Seriously, its head-out-of-sandpile time here. Enterprise admins and
dsl/cable-modem folks use DHCP today so that they can have some
flexibility to migrate their services around if there are issues,
concerns, or new/better platforms that could be taken advantage of by
their users. If you do not provide that level of flexibility with the
same (or better hopfully) overhead you've lost the game.

If your 'network' is 5 machines in a basement all with ssh+root then
this conversation doesn't matter. If your network is a 50k+ mixed
platform global enterprise network you are F'd with a capital F if you
have to spend cycles running to all 50k+ machines to update their
resolver settings (in just the simplest of examples).

-Chris

16

and trying to keep 50k machines updated with proper resolvers (in the
simplest example) is easier with RA than DHCP how?

do you really mean skip RA or all of autoconf?

i want to explore RA(only) + DHCP, to save me from running a routing
protocol or vsrp to have redundant exits for a LAN.

randy, about to go off net, heading for a rural onsen & ryokan

17

> and trying to keep 50k machines updated with proper resolvers (in the
> simplest example) is easier with RA than DHCP how?

do you really mean skip RA or all of autoconf?

I think what makes sense is to use the parts of ipv6 that work well,
RA, but blend in what works already well and is folded already into
the enterprise model... dhcpv6.

i want to explore RA(only) + DHCP, to save me from running a routing
protocol or vsrp to have redundant exits for a LAN.

ok, somewhere there's a blend of things that will work for enterprises
and cable/dsl/mso folk. I think that some enterprises don't mind
'random address selection' while they want to pass out info required
(cause like it or not DNS is required) in a sane manner, one that's
even part of their current method.

RA/Autoconf won't work at all for some folks with deployed server
infra, all they want is a method to get a static addr on a box and
route properly. Perhaps RA gets them the 'route properly' part easily
enough but I can imagine places where that is even turned off.

Basically my rant here is that autoconf isn't enough, it's not even a
starting point for enterprise folks who rely on DHCP for all it's
bells + whistles. Taking a giant leap backwards is never going to fly
for them, so wake up and smell the cafe, dhcpv6 needs to be viable,
workable, operable, built-in and well tested.

randy, about to go off net, heading for a rural onsen & ryokan

have fun!

-Chris

18

Christopher Morrow wrote:

RA/Autoconf won't work at all for some folks with deployed server
infra, all they want is a method to get a static addr on a box and
route properly. Perhaps RA gets them the 'route properly' part easily
enough but I can imagine places where that is even turned off.

I think it would be great to be able to do hybrids with RA for other situations where a shotgun approach is ok but I do not think we will want to use that in server environments. Hopefully vrrpv6 will work
with RA turned completely off.

- Kevin

19

RA/Autoconf won't work at all for some folks with deployed server
infra,

That's just IPv4 uptightness. As long as you don't change your MAC address you'll get the same IPv6 address every time, this works fine for servers unless you need a memorable address. BTW, I don't know anyone who uses DHCP for their servers.

Hopefully vrrpv6 will work with RA turned completely off.

With router advertisements present you don't need VRRP because you have dead neighbor detection.

20

Iljitsch van Beijnum wrote:

RA/Autoconf won't work at all for some folks with deployed server
infra,

That's just IPv4 uptightness. As long as you don't change your MAC address you'll get the same IPv6 address every time, this works fine for servers unless you need a memorable address. BTW, I don't know anyone who uses DHCP for their servers.

Hopefully vrrpv6 will work with RA turned completely off.

With router advertisements present you don't need VRRP because you have dead neighbor detection.

And that helps the hosts on the same l2 segment that need different
gateways how? Or hosts with access to multiple l2 segments with
different gateways?

RA is a shotgun. All hosts on a segment get the same gateway. I have no idea what a host on multiple segments with different gateways would do. Hosting environments can get complex thanks to customer
requirements and baggage from previous migrations. Load balancer and VPN
configurations are common culprits but there are also cases where
servers need different gateways for routing policy reasons. All of this
is easily accommodated with static gateways and the redundancy provided
by vrrpv4. Please don't take that away from us. Migration to v6 will
be difficult enough without subtracting functionality from our existing
tools.

Other than that I look forward to seeing what wonderful things we can
do with RA to simplify things in cases where shotgun == ok.

- Kevin