nanog mailing list archives
Re: IPv6 Deployment for the LAN
From: Owen DeLong <owen () delong com>
Date: Thu, 22 Oct 2009 20:50:04 -0700
On Oct 22, 2009, at 4:12 PM, Karl Auer wrote:
Current practice in the environments I know that are doing this is that groupsOn Thu, 2009-10-22 at 11:03 -0400, 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 theirpresence, 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.It would be a tool, and if someone wants to use a tool, they can. It won't be my thumb they hit :-) But I can't see how a DHCP server can know enough about the routers to be able to send out useful discrimination information. So it will have to be manually entered, or come from an IPAM, or...
of hosts are maintained in a database (including MAC addresses) and this database is used to build the DHCP configuration. The host groupis assigned a default router address which is actually a VRRP group address.
The routers then elect an appropriate VRRP active/standby configuration and
the hosts route via the Active router for their VRRP group. If the hostadministrators find that a host needs to be part of a different VRRP group for whatever reason, there are tools at their disposal to address that issue.
DHCP lease times can be short since the addresses are actually static anyway (yes, lots of people use DHCP to assign static addresses inproduction environments because it allows table-driven central management
of host assignment).
Nor can I see how the DHCP server can identify the routers to the host except by their addresses, and these can change or be removed without the DHCP server finding out.
In most environments I know, there are addresses reserved for the VRRP groups that the routers participate in and the router administrators are well aware of the damage they will bring if they change them without extensive planning and notice.
The only way I can see it working is if the host were smart enough tocompare the DHCP router discrimination info with the information it has received via RA and delete mismatches, or possibly just revert to usingRA information if any mismatches at all are detected. That would be an item the DHCP server could specify as well - what to do in case of a mismatch. It could even be specified on a per-router basis, though the whole thing seems to be getting a bit unwieldy now.
That would be a terrible choice because you have eliminated one of thekey reasons that some installations need DHCP to assign router information
instead of RA. While what you propose is probably technically cleanerfrom a pure protocol design perspective, the reality is that pure protocol
design is not how the real world thinks or operates. In the real world, one must make the protocol adapt to the business rules and other odd parameters that don't always make logical sense from a protocol design perspective. This is one such example when you have different administrative groups responsible for hosts and routers. <SARCASM>I know it is rare to find an enterprise where the network infrastructure is not run by the same group that does the systems administration.</SARCASM> But in many of these organizations, this means that having the router specify the default gateway to the host is not going to work well for the systems administrators. In today's world, they don't have to worry about this and, the network group, surprisingly, is pretty good at keeping the VRRP groups numbered as they are supposed to be (usually .1, .2, etc. or .254, .253, .252, etc., or whatever the first/last addresses of a segment happen to be).
The DHCP servers will not be on the same subnets as all the routers involved, so they can't sniff the RAs themselves - unless we set up an RA relay... hmm.
They don't need to.
Why do router preferences instead of just routers? Sure, the DHCP serverI don't see DHCP-delivered router preferences as being something that will "break the Internet". In the vast majority of cases they will be unnecessary. For those that do need it though, and if it can be done, why not?
doesn't know which router should be doing the routing, but, VRRP cantake care of that as it does today. The DHCP server just needs to assign
the VRRP group. Owen \
Current thread:
- Re: {SPAM?} Re: IPv6 Deployment for the LAN, (continued)
- Re: {SPAM?} Re: IPv6 Deployment for the LAN Matthew Petach (Oct 26)
- Re: {SPAM?} Re: IPv6 Deployment for the LAN TJ (Oct 22)
- Re: {SPAM?} Re: IPv6 Deployment for the LAN Owen DeLong (Oct 22)
- Re: {SPAM?} Re: IPv6 Deployment for the LAN Joe Maimon (Oct 22)
- Re: {SPAM?} Re: IPv6 Deployment for the LAN TJ (Oct 22)
- Re: {SPAM?} Re: IPv6 Deployment for the LAN Owen DeLong (Oct 22)
- Re: {SPAM?} Re: IPv6 Deployment for the LAN David Barak (Oct 22)
- Re: IPv6 Deployment for the LAN Vasil Kolev (Oct 22)
- Re: IPv6 Deployment for the LAN James R. Cutler (Oct 22)
- Re: IPv6 Deployment for the LAN Karl Auer (Oct 22)
- Re: IPv6 Deployment for the LAN Owen DeLong (Oct 22)
- Re: IPv6 Deployment for the LAN Mark Smith (Oct 22)
- Re: IPv6 Deployment for the LAN Iljitsch van Beijnum (Oct 22)
- Re: IPv6 Deployment for the LAN Joe Maimon (Oct 22)
- Re: IPv6 Deployment for the LAN bmanning (Oct 21)
- Re: IPv6 Deployment for the LAN Iljitsch van Beijnum (Oct 22)
- Re: IPv6 Deployment for the LAN bmanning (Oct 22)
- Re: IPv6 Deployment for the LAN Perry Lorier (Oct 22)
- Re: IPv6 Deployment for the LAN bmanning (Oct 22)
- Re: IPv6 Deployment for the LAN Perry Lorier (Oct 22)
- Re: IPv6 Deployment for the LAN trejrco (Oct 22)