[Chapter-delegates] ISOC Briefing Papers on IPv6

[Phil Roberts]

Thanks for your comments, Marcin.  Since you won't be on the call I'd 
like to take a moment to point out some things that we are aware of that 
may not be specifically covered in the public policy briefing papers.  
My comments are embedded below.

Regards,
Phil


Marcin Cieslak wrote:
> Anne Lord wrote:
>   
>> Dear Colleagues,
>>
>> This is just a friendly reminder that the next briefing paper discussion
>> will be held on 26th August at UTC 10.30 and UTC 20.00 (subject to a
>> quorum of 5 chapter attendees for each call).
>> The papers are on IPv6, specifically:
>>
>> a) IPv6 deployment: State of play and the way forward:
>> http://www.isoc.org/pubpolpillar/docs/ipv6-way-forward.pdf
>>
>> b) IPv6: Why and how Governments should be involved:
>> http://www.isoc.org/pubpolpillar/docs/ipv6-government-role.pdf
>>     
>
> I am afraid I might not be able to join the conference, therefore I put
> my first thoughts here, from the point of view of a consultant who
> sometimes tries to "sell" the idea of IPv6 to my customers:
>
> 1. An issue with IPv6 Address Aggregation
>
> During a session on IPv6 with IP community in Poland organized by
> national telecommunications regulator one major issue popped up: it's
> the portability of smaller IPv6 spaces in spite of aggregation. I think
> this is a real problem in the IPv6 take-up - aggregation of addressing
> space that will preclude some players (for example large internet
> portals and content providers) to quickly change their upstream
> providers, as this is possible now with a small PI (Provider
> Independent) space (even /24). I don't know what's the current status of
> IETF work on this and I'd like to find out.
>   
I believe this is more of an operational issue and an RIR policy issue 
than it is a standardization issue.  The operational issue being that 
aggregation is the main tool we have in routing to contain the 
potentially explosive growth of routing and forwarding tables in 
routers.  The RIR policy issue that would be specifically pertinent to 
Poland would be discussed in RIPE.  IPv6 PI is available in the RIPE 
service region and the policy is documented here:
http://www.ripe.net/ripe/docs/ripe-472.html#_8._IPv6_Provider.

> 2. We should put more stress on benefits of NAT-free environment.
>
> - I think there are some applications already there that most of the
> people know. One is VoIP (but everyone uses Skype, so who cares) and
> gaming (and this is causing some pain, salvaged with UPnP). Gaming
> recently takes up also as the instant messaging and voice service, that
> was demonstrated recently as the means of avoiding Internet censorship
> in some countries.
>
> - Another (although niche) example is distributed software revision
> control used to maintain the computer source code for programmers (with
> new models exhibited by git, mercurial, darcs and others) where it's a
> real peer-to-peer mesh of developers machines without any need for
> version control servers. This has been recently a real hit and many (if
> not most) of the open-source projects have already adopted them. I would
> definitely watch this movement since open source development in my
> opinion is the early adopter of any Internet technology. We wouldn't
> have Wikipedia for example if programmers didn't start to put their
> notes on a quickly-editable Wiki site. The benefits of reaching any
> device directly are obvious and no kind of NAT workaround like
> Application Level Gateway or port redirection is likely to work
> effectively.
>
> - Once we have admitted mistake and realized that a dual-stack approach
> won't take us anywhere I think we should start advocating use of IPv6
> instead of the RFC1918 behind NATs. I think this is a subject of a
> recent IETF work and is definitely worth watching. That's more or less
> the way free.fr deployed IPv6 in their infrastructure for customers.
> This the reason why Comcast needs to move (not enough RFC1918 space).
> I think that also many corporations may solve their extranet and access
> segmentation woes with moving into globally-unique IPv6 internally
> (barring crappy applications). I was personally trapped in this problem
> many times trying to coordinate "pseudo-global" RFC 1918 deployments of
> neighboring corporations ("oh, you have 10/8 too? So let's put a small
> 172.16.0.0 network between us and let's double-NAT.").
>
> - Let's have a look at the Google Wave. There is no reason why this
> technology could not break free from the client-server XMPP model and
> move onto peer-to-peer exchange using something like SIP or whatever. We
> just shouldn't be afraid to say the "dirty (p2p) word". I think there is
> tremendous potential in those kind of interactions (regardless whether
> waves will catch on or not).
>   
As you know, the issues and complications arising from NAT are 
well-known and have been documented (see RFC 2993 for example).  The 
IETF continues to explore issues arising from these.  At the IETF in San 
Francisco there was a BOF on shared addressing.  Mat Ford of our 
standards and technology department produce an Internet Draft as input 
to that discussion.  It can be found here:
http://tools.ietf.org/html/draft-ford-shared-addressing-issues-00.  That 
document is being updated based on more information that has been 
learned and discussed since the time of that document.  We expect to 
have a revised draft submitted in time for IETF76.
> 3. Security
>
> Lots of people say that using publicly-reachable addresses is a threat
> to security. The false sense of security given by NAT has grown deeply
> into network manager's mindsets. I usually keep saying that addressing
> and routing are not security and too complicated schemes usually
> backfire with security holes resulting from misconfiguration. A quick
> way to demonstrate this are all client-related attacks especially on web
> browsers or via email spam. Botnets operate fine mostly behind NATs, too.
>
> I spoke recently with a top-level technical executive of a huge media
> company that was afraid that some provider is going to use public IP
> addresses to multicast some multimedia content to them. I had to explain
> that there's nothing wrong in using public IP addresses for
> communication. (Unfortunately this was about IPv4, but maybe I will get
> another call from him someday).
>
> 4. Awareness
>
> I seriously think we should run TV ads on IPv6. I have some ideas if
> needed :) I looked recently on YouTube and the only cool thing I could
> find was this:
>
> http://www.youtube.com/watch?v=_y36fG2Oba0
>   
You might also want to check out: http://www.ipv6actnow.org/info/video/.


> Nice, but this is not enough.
>
> I was recently amazed that middle-level broadband Internet marketing
> staff at one company didn't have a clue what an IPv6 is! They are
> actually preparing itself to deploy an infrastructure that could
> potentially support IPv6 from day one and they  didn't even know they
> could make an IPv6 offering part of the product.
>
> The reason for this is probably because IPv6 is still being considered
> as the toy for techs and it hardly ever leaves the data center basement.
>
> 5. Government involvement
>
> If everything else fails, call the government :) I must admit I am
> really ambivalent on this. On one hand, it's the government that created
> and funded ARPA and the rest is history. One the other hand, it all
> looks all-too-similar to the OSI protocols case. I am having too much
> doubts and trouble on the government possibly regulating IP (call it
> NGN) networks. Sure, the paper does not call for regulation, but some
> gentle methods, but at least in Europe we are in the middle of the
> process for the governments to "crack down" on the evil on the Internet.
> It's hard time to explain that Internet does belong neither to telco nor
> media regulation.
>
> I would say that the IPv6 problem is within marketing department and not
> public policy.
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Chapter-delegates mailing list
> Chapter-delegates at elists.isoc.org
> http://elists.isoc.org/mailman/listinfo/chapter-delegates
>