[v4v6interim] Scenarios feedback

[Nathan Ward <[e-mail]>]

I was hoping to get some of this stuff across earlier, but remote  
feedback is a bit difficult. This is a bit rushed to get it to the  
meeting in time, please talk to me on Jabber for clarification, I am  
also listening on the conference bridge and can see the camera.

Slide 2, the one with the graph showing the "reality" of the lack of  
IP adoption:
I disagree with this "reality". I believe the curve to be much closer  
(in angle) to the "size of the Internet", and perhaps it is even  
steeper.
- Vista has IPv6 support, Teredo, 6to4. New Internet users are likely  
to be on Vista vs. XP
- XPSP2 has IPv6 support for anyone who has turned it on. Peer to peer  
is encouraging people to do this. The most popular peer to peer app  
(uTorrent) even has a "Turn IPv6 on" button in its preferences now.
- Some CPE devices (Airport Extreme, Linksys Business whatever) have  
IPv6 support, and 6to4. These devices are getting OS X hosts online.
- Linux has Teredo and 6to4, there appears to be many Linux Teredo  
users, especially in the peer to peer population.

What is left? XP prior to SP2, OS X users without a 6to4 router or  
native connectivity, Linux users who haven't configured IPv6, and  
embedded devices. I'll go over each below:
- XP Prior to SP2. My assertion is that 99% users in this situation do  
not have a need for end-to-end IPv4. CGN will work fine for them.
- OS X users without a 6to4 router or native connectivity. This is a  
problem. Perhaps Apple will write a Teredo stack? Again, OS X users  
who don't upgrade to the latest OS are unlikely to have a need for end- 
to-end IPv4. There is a solution here already though, and that  
solution is Teredo.
- Linux users without IPv6. Tell them to configure it. It's 20  
commands at most.
- Embedded devices. These are built to work in many situations, so  
relying on non-NATed IPv4 or NAT-PMP or whatever is unlikely.


Comments on Scenarios 1, 2 and 3 collectively:
- We are caring about IPv4 right now because of the perceived need for  
end-to-end IPv4, or more specifically, the ability for end users to  
have ports open to the public Internet, either by "port  
forwarding"/"pin holing" or whatever.
- Applications that require this are, for the most part peer to peer  
applications. Bit torrent, Skype, etc.
- Bit torrent has IPv6 support, and combined with my previous comments  
about IPv6 "reality" we see that bit torrent will not be adversely  
affected.[1]
- Skype already gets around NAT, using non-NATed nodes. Skype could do  
IPv6 easily, and as per bit torrent get wide adoption.
- The non-peer to peer case, ie. home users running servers - If they  
must, they can buy a premium service from their ISP to get a non-NATed  
address. If the ISP doesn't offer this, they lose some customers[2],  
so it's up to them.
- Users of peer to peer applications are likely to upgrade their apps  
and OSes in the next year or so, they are "power users".
- CPE/GW boxes are for a large part not upgradable. Many providers  
around the world do not provide their customers with CPEs, and forcing  
the customer to purchase new hardware so that it keeps working is a  
hard sell. "Buy this so your Internet keeps working" is the same as  
saying "Deploy IPv6 so your Internet keeps working" to ISPs - except  
ISPs understand the problem and have still not done it.
- Dual stack operational overhead is lower than developing, deploying,  
and maintaining a 4 over 6 solution, especially when such a solution  
has a lifetime of only a few years. We can do dual stack *today*.


Scenario 4: IPv6 hosts reaching IPv4 servers.
This is not hard, but we need some standardisation around it.

Scenario 5: IPv4 hosts reaching IPv6 servers.
Until IPv6 is widely deployed, anyone wanting to run a server can buy  
a premium service from their ISP and get IPv4 addresses.
Port agility (in the application) is not an option here. The reason  
this scenario exists is because of legacy operating systems and  
applications.


Summary (please read aloud, but refer to the email for further  
thoughts/background):
- Let's not try and develop a complicated super-solution for IPv4.  
IPv6 is hard enough for ISPs to understand+train etc. as it is.
- We care about IPv4 for end to end/peer to peer.
- IPv6 is in wide deployment in peer to peer already, peer to peer  
users regularly upgrade. The solution to IPv4 peer to peer is IPv6,  
and it is already deployed.
- Therefore IPv4 end to end is not a problem.
- We should not focus on solutions that require CPE/GW upgrades  
because many providers do not provide CPE/GWs.
- Scenario 4 is solveable with NAT-PT.
- Often cited NAT-PT scalability problems (in the v6 -> v4 direction)  
are the same as IPv4 NAT scalability problems, and we have to solve  
IPv4 NAT scalability so let's do both.
- If we can't do NAT-PT in v6->v4 direction, dualstack exists.
- Apart from scenario 5, these problems are either all non-issues (in  
my view), or are solved already with existing protocols that vendors  
aren't doing yet, or aren't doing well enough.
- How do we solve scenario 5?
    o We cannot do port agility. The reason this scenario exists is  
because of legacy operating systems and applications, and we want to  
support those users who have not upgraded. Port agility requires  
application modification.
    o Servers have to have IPv4 until IPv6 is widely enough deployed?  
Seems feasible, as we're all doing CGN there is lots of IPv4 space  
free for servers now, provided RIRs reclaim it.


--
Nathan Ward

[1] See my talk from APNIC26 RE bit torrent IPv6 usage. With uTorrent  
supporting IPv6 (since then) this problem really does not exist anymore.
[2] Note that most customers who want to run home servers are the  
"high usage" customers, so most ISPs would be happy to get rid of  
them :-)


_______________________________________________
v4v6interim mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v4v6interim