[134539] in North American Network Operators' Group
Re: NIST IPv6 document
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Jan 6 20:18:35 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <AANLkTik3yvdavWAXDrKE0f9Cq-LGt3q7LXHxtt=jJ5-0@mail.gmail.com>
Date: Thu, 6 Jan 2011 17:12:19 -0800
To: Marcel Plug <marcelplug@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
This would break dead-neighbor detection, but, I'm not sure that's =
necessarily
a problem for end hosts at the local router level.
It is touted as one of the IPv6 features, but, I'm not sure how valuable =
it is as
a feature.
Owen
On Jan 6, 2011, at 7:37 AM, Marcel Plug wrote:
> Perhaps we're reaching the point where we can say "We don't need an ND
> table for a /64 network". If the ethernet MAC is embedded in the IPv6
> address, we don't need to discover it because we already know it. If
> the IPv6 address has been manually configured on a host, perhaps that
> host should now accept traffic directed to the MAC that the lower 64
> bits of the IPv6 address would translate to.
>=20
> Perhaps this idea has been discussed somewhere and discarded for its
> flaws, but if not, perhaps it should be :-).
>=20
> Marcel
>=20
> (First post by the way, go easy on me :-)
>=20
> On Thu, Jan 6, 2011 at 10:19 AM, Jack Bates <jbates@brightok.net> =
wrote:
>>=20
>> On 1/6/2011 12:26 AM, Joe Greco wrote:
>>>=20
>>> A bunch of very smart people have worked on IPv6 for a very long
>>> time, and justification for /64's was hashed out at extended length
>>> over the period of years.
>>=20
>> NDP should have been better designed. It still has the same problems =
we had
>> with ARP except the address pool has magnified it.
>>=20
>> Routers should have 1) better methods for keeping ND tables low (and
>> maintaining only valid entries) or 2) better methods for learning =
valid
>> entries than unsolicited NDP requests.
>>=20
>> This isn't to say the protocol itself is a waste, but it should have =
taken
>> in the concerns and developed the mitigation controls necessary as
>> recommendations to the implementers.
>>=20
>>=20
>> Jack
>>=20
>>=20
