Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt]

[Ray Hunter <[e-mail]>]

> Lorenzo Colitti <mailto:[e-mail]>
> 10 January 2014 06:01
>
>
>     Ideally, that ability to control/register active /128's should not
>     rely on cooperation of L2 switches or other LAN functionality that
>     requires purchasing new switches, or constant MIB scanning.
>
>     I think that's a valid problem statement, and assigning >>/64
>     (purposefully breaking SLAAC, whilst deploying stateful DHCPv6, or
>     static addressing) is one way to address that problem.
>
>
> In your network you are free to assign addresses exclusively using DHCPv6.
>
> *However* - if you are doing this for the purpose of tracking, that 
> only makes any sense at all if the current switches you have (since 
> you've already said you're not going to buy new ones) can snoop DHCPv6 
> requests for address assignments enforce IPv6-to-MAC address mappings.
>
> Do they?
>
You are apparently imposing a model which assumes a single management 
vendor is responsible right up until the edge of the network at port level.

That is rarely true in any enterprise I've worked on. They are not my 
customer's switches. They don't manage them at all. They subcontract 
that to multiple parties.

In the case of multiple management providers, people need to protect 
their own services from the failings of others.

If a site is under autonomous management (e.g. trusted 3rd party) then 
they may be assigned a /48 in your model.

OK they're responsible for their own /48 and they can suffer the 
consequences of poor management of devices in their site.

But problems in their /48 with a rogue node assigning zillions of 
addresses and creating zillions of sessions should not spill over into 
the rest of the network managed by others.

WFQ QoS (and many other processes which requires tracking of individual 
sessions or IP addresses) running in another vendor's network should not 
fail because of a single node in a single 3rd party network swamps an 
address/session table.

I think that people need some way of limiting the number of active 
/128's at the network-network interface. It would be even better if we 
could either register or control to the /128 and identify those to a 
host or user.

One way of doing that is to agree with trusted 3rd party sites (which 
generally only have a tiny number of hosts allowed to communicate across 
the boundary) to only assign an agreed /120 out of their /48 allocation, 
which requires prefix lengths >>64 (this ID) or at least the ability to 
apply ACL filters >> /64.

Another way is source address validation at the edge, with limits 
assigned on a first come first served basis.

Another is to ban all processes that need to track an individual IPv6 
address.

Another is to contract that the site themselves are responsible for 
limiting resource depletion attacks, but I'd still want some protection 
on the receiving side.

I'd rather be tracking the 100K nodes that I know should be on the 
network out of a potential 24*2^16 addresses, rather than trying to stop 
a 100 zillion anonymous nodes who I can't even identify so that the 100K 
can work.

DHCP has been successfully implemented in multi-vendor environments. The 
local LAN manager/outsourcer only has to configure up the LAN interface 
either the correct IP address and subnet mask, and point a DHCP proxy at 
a regional server (managed by someone else) They can make changes within 
a site autonomously without bothering the central team, and it all just 
works.

DHCPv6 potentially can provide a form of centralised registration (and 
then be linked to admission control, or at least give cooperating end 
nodes a higher QoS than unidentified end nodes) and support a similar 
operations model.
You could also allocate a /64, configure a DHCPv6 address pool to assign 
addresses from a range >>64 and apply and ACL, or assign and allocate 
 >>64 prefix length (which seems easier).


Because if they don't, disabling SLAAC gives you no security at all, 
because malicious hosts on your network will still be free to create and 
use arbitrary IPv6 addresses, which you will not be able to track. In 
fact, this gives you the same level of security as you could by 
disabling privacy addresses and using autoconf - malicious hosts can 
still do what they want, and for well-behaved hosts, instead of having 
the MAC address in the IPv6 address, you now have to go and get it from 
the DHCPv6 server logs. Lose/lose.

That is also a problem. The assumption seems to be that there has been 
of smart nodes and a dumb network that does not run any processes 
requiring differential services or that tracking of individual end hosts 
is universally bad.

But I thought we'd established that we're not exclusively talking about 
forcing use of particular addresses for all machines, rather 
establishing which nodes are genuinely active, and attempting to 
establish centrally what machine they are being used by.
>
> Or - as Tim points out, SNMP scraping will do this securely for you 
> today, and vendors are already building better and more scalable 
> address registration notification features (syslog, etc.) into switches.
Not everyone allows SNMP access from other management vendors in a multi 
vendor environment. Not everyone feeds syslog to other management vendors.
Again, you are imposing an alien operations model. It imposes polling, 
It imposes inter-vendor cooperation and access to all remote devices via 
a management protocol.
Every time a switch on any one of 1000 sites changes, you're going to 
have to update your central poller. A central registration model avoids 
that overhead.
> And if you're not doing this for the purpose of tracking, then why are 
> you doing it? Is it just because it's what you do in IPv4? If so, then 
> sorry, that's not a valid technical argument.
At the risk of repeeating myself: helpdesk call correlation, problem 
correlation, log correlation, ability to track to /128 (for future 
filtering or tracking or resource protection of processes and devices 
within the network that rely on databases or caches keyed by IP address)

In IPv4, this protection happens automatically due to address scarcity, 
without doing anything else.

IPv6 /64 breaks address scarcity.


-- 
Regards,
RayH