IPv6 operational issues

[Alain Durand <Alain.Durand@Sun.COM>]

I could not present this issue this morning, as the meeting was running 
out of time.
We probably collectively (wg chairs, IAB members, wg group 
participants, myself)
need to do a better job at time keeping.
IMHO, saving meeting time for discussing operational issues is 
important.

That said, here is a link to my slides:

http://playground.sun.com/ipv6/IPv6ONbyDefault.pdf

The bottom line is that while deploying IPv6 internally, we have 
identified 2 cases that are problematic:
1- a node with v6 enable (on by default) in a v4 RFC1918 network with 
no v6 connectivity.
    With current Neighbor Discovery 'on-link' assumption, current 
destination address selection
    rules and current stub resolver behavior, this can lead to 
unacceptable delays
    before connections succeed.
    A fix is necessary in at least one of the 3 items described above.

2- a dual stack node in a foreign v4/v6 network connecting to a v4/v6 
enterprise network
    via a v4 only VPN.
    a) there are some serious security issues with this model.
    b) TCP SYN time-outs induce unacceptable delays.
    This can be fixed operationally, either by getting a v6 aware VPN or
    turning IPv4 off before firing up the v4 VPN.

	- Alain.