NIST IPv6 document

Thu Jan 6 14:01:00 UTC 2011

> On Wed, Jan 5, 2011 at 10:51 PM, Joe Greco <jgreco at ns.sol.net> wrote:
> >> On Jan 6, 2011, at 12:54 PM, Joe Greco wrote:
> ...
> > To say that "the endpoint *will be found*" is a truism, in the same
> > way that a bank *will* be robbed. =A0You're not trying to guarantee that
> > it will never happen. =A0You're trying to *deter* the bad guys. =A0You wa=
> nt
> > the bad guy to go across the street to the less-well-defended bank
> > across the street. =A0You can't be sure that they'll do that. =A0Someone
> > who has it out for you and your bank will rob your bank (or end up
> > in jail or dead or whatever). =A0But you can scare off the guy who's
> > just looking to score a few thousand in easy cash.
> >
> > Making it harder to scan a network *can* and *does* deter certain
> > classes of attacks. =A0That it doesn't prevent every attack isn't a
> > compelling proof that it doesn't prevent some, and I have to call what
> > you said a poor argument for that reason.
> 
> Hi Joe,
> 
> I think what people are trying to say is that it doesn't matter whether
> or not your host is easily findable or not, if I can trivially take out you=
> r
> upstream router.  With your upstream router out of commission, the
> findability of your host on the subnet really doesn't matter.  Once the
> router is gone, so is your host, no matter how well hidden on the
> subnet it was.
> 
> So, the push here is to prevent the trivial ability to take out the
> upstream routers, so that the host-level issues will still matter, and
> be worth discussing.
> 
> Hope this helps clarify the reason for the overarching concern
> about the /64 subnet size.

I completely understand that issue.  However, I feel that this is not
a hopeless quagmire.  We've frequently run into major problems in IP
engineering in the past, and have coped with them with varying degrees
of success (smurf and CIDR pop to mind).

We've also shown that the underlying protocols and technology are
open to tinkering where necessary; consider 802.3az.

I basically agree that there may be some issues with the current IPv6 
NDP (etc) system.  We actually have issues with the current IPv4 ARP
system, too (think spoofing etc).  However, I think we might be looking
at this the wrong way.  Instead of vendor knobs to change the IPv6 
protocol, which may interfere with both ethernet *and* v6, it seems to
me that maybe the problem can be solved just for the ethernet portions
of the problem.  For example, while there might be a /64's worth of 
address space on an interface, I'm *pretty* sure that the design goal
isn't actually to support all that.  Further, a router's need to talk
to that network will be isolated to that interface.  I wouldn't be too
shocked to see the NDP protocol morph a little to allow routers to
more easily maintain a neighbor list in local (per-ifc) silicon, 
rather than in expensive router TCAM, since the best use of TCAM isn't 
ARP^WNDP anyways.  The fact of the matter is that silicon is cheap and 
getting cheaper.  We will see ethernet switches allowing the learning 
of MAC info for NDP purposes, just as we currently have ethernet 
switches policing MAC's for IPv4 sanity purposes.  Routers will 
probably need to do some policing of NDP rates, but also we may see
better silicon to help with ethernet.

There may be ways to fix the *ethernet* /64 issues in IPv6.  We could
be talking constructively about that.  Instead, I'm seeing what seems
to me to be dislike of /64's in general.  I don't really care to get
into arguments about that, that ship sailed long ago, and those who 
missed the boat fighting it at the time aren't going to get any joy
here.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.