Re: [v6ops] MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt

[Andrew Yourtchenko <[e-mail]>]

Hi Leo,

On Fri, 11 Jul 2014, Liubing (Leo) wrote:

>
> Now there are some enterprise/campus networks under real use or 
>considering using L2 networks. Some are aiming at better user isolation
>through VLANs (some even consider QinQ mechanism); while some are aiming 
>less configuration/management than the traditional L3 networks. So there 
>would be thousands of hosts aggregated to the core switch (normally there 
>are two core switches stacked together, but only share one cache space). 
>As IPv6 is beginning real use, for example, some of the campus networks 
>are already dual-stack, and the majority of the hosts are Win 7, we once 
>observed in one campus that DHCPv6/SLAAC are both enabled, each Win 7 
>host had 4 IPv6 addr (SLAAC+DHCPv6+Privacy+link-local)+1 IPv4 addr.

If the majority of the hosts are Win 7, and are under the control of the 
administrator, this looks more like a misconfiguration rather than 
anything else: clear the "A" bit on the prefix, and they'll half the
address usage - down to just link-local and DHCPv6-based.

>
> Current high-end switch can certainly fulfill the thousands of users' 
>IP-MAC entries, however, the forwarding performance would be a 
>significant redundancy, which would cost more budget than expected. This 
>is something that won't happen in IPv4, so I thought maybe this could be 
>considered as an IPv6 networks operational issue, and took the issue into 
>the draft and gain some opinions in the list.

I'd say it's a question of different scaling requirements, depending on 
the network design.

--a

>
>>> Plus, an IPv6-MAC binding would cost more cache space than an IPv4-MAC
>> binding (2-4 times due to implementation).
>>>
>>>> I re-read the original mail starting this thread and the problem
>>>> description there to me boils down to two issues:
>>>>
>>>> 1) one IP node has more IP addresses in version 6 than in version 4.
>>>> 2) an IP address takes more lookup space in version 6 than in version 4.
>>>>
>>>> Do I grok it right ?
>>> [Bing] Basically yes. This is one of the problems cause by multiple
>>> IPv6 addresses in draft-liu-v6ops-running-multiple-prefixes.
>>
>> Ok, then I think that's a tricky one - we can not decrease the number of bits
>> in IPv6 address, nor get the end hosts to go back to ARP for address
>> resolution :-)
>>
>> Also, if iOS 8.0 indeed changes the MAC address upon the wireless
>> connection, the problem is just about to get much worse and not
>> IPv6-specific ;-)
>>
>> So, I think there are several means to combat the lookup space churn:
>>
>> 1) IPv6-only networks. We can't do that today and IPv4 is relatively not
>> *so* much but it's something.
>>
>> 2) Table maintenance/cleanup mechanisms. These appear to work today
>> reasonably.
>>
>> 3) provisioning hardware according to anticipated scale - and either using
>> larger router boxes, or splitting large L3 domains into several smaller
>> segments, like Mikael mentioned.
>>
>> 4) using DHCPv6-only allocation of addresses, with one address per host
>> assignment.
>>
>> Do you think there is something more that is needed besides the above
>> approaches to steer the addresses on the host ?
>
> [Bing] Thanks for the proposed approaches. It seems that's what we can do so far in operation perspective.
> As the opinions raised in the mailing list, people tend to consider it as a network design issue rather than operational issue. I will reflect the opinions in the next version of the draft.
>
> Best regards,
> Bing
>
>> --a
>