Jared,
Actually, if you look at the question from a slightly different
perspective, there is more than one "legitimate operational reason."
The "recast" version of the question is what is the cost to the
network if a host IS required to know this information (for reasons
having not a lot to do with making the host itself work correctly),
and "knows" incorrect information?
The first (and probably most important) reason why networks
should not depend on hosts having the correct information, is the
likelihood that a host (which may or may not be under the operational
control of the network operator) might be misconfigured.
DHCP has done much to fix this problem, at least for the hosts
that are cooperative. But there is always the possibility that the
need to keep the host updated (via DHCP, for instance) may be less
than healthy for the host. And - quite frankly - the host does not
really need to know this information in most cases.
A second reason is more philosophical (though the above reason
is one aspect of this higher-level "philosophical" reason) - it is
not a good idea in general to force a "need-to-know" on entities that
do not themselves have an existing "need-to-know." Doing so has the
undesirable effect of increasing the amount of knowledge that needs
to be correctly "spread around."
--
Eric
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Jared
Mauch
Sent: Sunday, August 15, 2010 9:07 PM
To: Hemant Singh (shemant)
Cc: ipv6 deployment prevention
Subject: Re: Router redirects in Node Requirements document
On Aug 15, 2010, at 8:35 PM, Hemant Singh (shemant) wrote:
> -----Original Message-----
> From: Jared Mauch [mailto:[email protected]]
> Sent: Sunday, August 15, 2010 4:18 PM
> To: Hemant Singh (shemant)
> Cc: Randy Bush; ipv6 deployment prevention
> Subject: Re: Router redirects in Node Requirements document
>
>
>> Fixing DHCPv6 and adding prefix-length/mask seems a much more elegant
> solution vs pushing redirect capability upon a large swath of devices.
>
> I and Wes disagree with adding any prefix length to DHCPv6. I believe
> Wes gave the reason to 6man mailer during the past 3 years. Rather than
> spend time to fish out the email, here is the text Wes that captures the
> gist of it.
>
> "The reason I think one separated prefix length from ND RA and DHCPv6 is
> that the router knows best what prefixes it can route to, and what is
> on-link/off-link, etc., because the router is responsible for the
> TOPOLOGY of the network. The DHCPv6 server knows best who is authorized
> to get an address, and what configuration information a client should
> get, because it is the CONFIGURATION/SECURITY authority. These are two
> separate concerns, and it is best to keep them separate. It's easier to
> manage TOPOLOGY in a distributed fashion. It's easier to manage
> CONFIGURATION/SECURITY in a centralized fashion."
Oh my.
So, hosts shouldn't have to know anything about their environment anymore and
this is just proxy-arp & redirects all over again?
Do you know what impact that has on IOS based devices? I suspect you've not
seen the operational impact as a result of such items, otherwise you would
understand how poorly vendors actually implement these features for the
operators. (Hence me raising the DoS issue).
Even with your aforementioned rate-limit items, this would possibly cause HA
issues with switchover should a prefix/next-hop change, or a router fail.
Is there a legitimate operational reason a host should not know the subnet
length it sits on?
- Jared
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
