3 Wednesday Plenary

Thursday Plenary

Current Meeting Report

30 July 2008  - IETF 72 Technical Plenary 
Acknowledgements: Mirjam Kuehne and Dow Street for keeping notes

* Welcome
* Alcatel-Lucent Host Presentation
* IRTF Chair's Report (see slides)
  	Aaron Falk
* IAB Chair's Report (see slides)
  	Olaf Kolkman
* RFC Editor Model (see slides)
   	Olaf Kolkman

Scott Bradner: Olaf said the decision about the RFC Editor contract
needs to be made by the end of august. Why?

Olaf: The process after august is as follows: IAOC wants to proceed
with an RFI, then RFP, then the vendor needs to be
contracted. Contract needs to be done in 2009.

Ray Pelletier: Q4-2008: RFI, Q12009: RFP itself, June: evaluation,
July-October: contracting, 2010: new vendor in place 

Scott: would have been nice to have more time for discussion

John Klensin: substantive comments on this topics have been delayed
for various reasons. There are comments being prepared. Will hit the
IAOC second half of August. Then they need to take them into account.

Olaf: True and it would be great to get comments before the second
half of August


Olaf: no open mic time today. If you need open mic time tomorrow, please
send mail before noon tomorrow

     [See http://www.ietf.org/proceedings/08jul/minutes/plenaryt.txt
      for the minutes of that session]

* Technical Topic:  IPv6 Experiences from the Field

- see introduction sent to ietf list (and panelists slides)

 Mark Kosters (ARIN)
 Alain Durand (Comcast)
 Shin Miyakawa (NTTcom)
 Lorenzo Colitti (Google)
 Stuart Cheshire (Apple)
 Gregory Lebovitz (Moderator)

== Mark Kosters (ARIN): IPv4 depletion and IPv6 adoption

Mark talked about the address allocation policies for the remaining
/8s as of June 2008. He explained that IPv6 space allocation happened
especially in the RIPE region and also in the APNIC region there is
quite a bit of activity and that various RIRs have IPv6 PI assignment
policies in place. He explained that the various RIRs are working on
policies with respect to the remaining IPv4 addresses.

ARIN and other RIRs have taken quite an aggressive policy to raise
awareness of v6 in the community. A lot of training, experiments,
research, lobbying is going on.

Mark encouraged everyone to participate in these awareness activities
in their perspective regions.

= Alain Durand (Comcast): Post IPv4 "Completion" 

IPv4 will not stop working! was the premise of Alain's presentation. He
explained how IPv6 could be integrated in a broadband network where
customers will work with legacy applications and OSes.

Alain provided some overview slides to show some transition
mechanisms that allow introduction of IPv6 into an IPv4 environment.

Shin Miyakawa (NTTcom): From IPv4 only to v4/v6 Dual Stack

Shin demonstrated some of the scalability issues with IPv4 carrier grade
NATs and demonstrated a transition scenario from an IPv4 only network
to a IPv4/v6 dual stack environment.

Lorenzo Colitti (Google): IPv6 deployment at Google

Lorenzo explained how IPv6 was deployed at Google. He explained that
the deployment was started as a side project and gained momentum. He
shared the operational lessons he learned during deployment and
stressed that IPv6 is not rocket science.

Stuart Cheschire (Apple): Apple IPv6 Experience

Stuart presented his experiences about adapting IPv6 in Apple
products. He focused on the decentive to use IPv6 that is caused by
timeouts caused by preference in nameresolution and connection
setup. He demonstrated how this is being dealth with in Apple's
products and argued for a socket API's that are able to deal with
names instead of address structures.


Gregory: what are your experiences with ops staff?

Alain: IPv6 addresses are not very easy to type or remember. 
We have to stay away from literal addresses as much we can
and use DNS.

Shin: many things have to be done manual

Lorenzo: ops team is pretty good. The only problems are when some
things that are designed differently (than in v4), it has to be
clearly documented and safe cards have to be implemented.

quality of connectivity of the v6 internet is important. state of
inter domain routing is more worrying than ops staff.

Gregory: have you had all equipment and features that you need? And
what are the gaps?

Alain: most difficult to get all the things in the back office. 

Mark: ARIN is trying to put all its services on v6. It's been a lot of
work. A lot of little things (like load balancing) are not there yet. 

Lorenzo: Although the product specs contained a check box for v6, it
had never been really tested. Errors only occured when there was v6
traffic and the routers crashed.

Gregory: Are you driving v6 to your customers or do they demand v6 from

Shin: we are pushing customers to use v6. 

Lorenzo: people seem to be pretty happy, occasional bug reports
(e.g. in Firefox).

Alain: not many customers care about if the applications run over v4
or v6. We have to make sure the Internet keeps growing, doesn't matter
if on v4 and v6 (will come automatically)

Gregory: sounds like you are driving customers to use v6. What Stuart
says: if they don't demand it, we have to make it really transparent
to the customers.


Remis Depres: I use v6 in my home every day. ...

Alain: there are different places with different constraints. What is
good for one ISP is not good for another.

Remis: would it not be interesting to analyze why this is the case?

Randy Bush: Shin and Alain, why aren't you beating up Cisco?  When
you do a protocol that is uncompatible on the wire, there needs to be
Carrier class nets: single point of failure. Because carriers do these
things with big ugly things in the middle. We instead push things to
the edges. NATs in the middle will break things and create walled
garden. Why don't you demand from DOCSIS to get NATs at the ends.

Alain: docsis is layer 2, not layer 3. We are not talking about
centralized carrier NAT. question is: where is this divide in the
network. Agrees that this is bad and provides a single point of
failure. NATs need to get close to the customer. 

Lorenzo: v6 end-to-end is the answer

Alain: we need to talk to applications developers. 

Shin: goal is to provide v6 and we need to bring it to the customers

Henning Schulzrinne: instead of sending individual bug reports to
application developers, it would be great to create a shame list ('not
compatible with the future') or to create a v6-ready sticker

Stuart: yes, good idea

Lorenzo: legacy applications are the problems

James Woodyatt: would be interested to do some analysis to figure out
how much it will cost an end-user to have a public v4 address?
Believes that this will be the incentive to use v6. 

Shin: we are undergoing that kind of research right now.

Mark: one new policy proposals is related to v4 address transfers. One
aspect of transfer is market based transfer. and that is currently not
allowed by the RIRs. ARIN has asked a lawyer to look into this and 
the result has been that an open market would be the best.

Ted Lemon: thinks that it is important for IETFers to use v6 at home.

Lorenzo: he tried to say that if you don't have v6 at home, the only
thing you can use is a tunnel. Don't do IDR through tunnels. don't
announce all your routes to use a tunnel. Instead try to interconnect
with other v6 networks.

Iljitsch van Beijnum: www.google.com only v4, ipv6.google.com only v6.
please add a domain name that has both.

Lorenzo: google has a /32 and we announce it. There are people who do
not have that luxury and have to multi-home.

William: Is DHCPv6 proxy available?

Alain: worked a lot with vendors and dhcpv6 community to make it
workable. Results quite successful. 

William: applications developers are all waiting to the peer to peer
readiness of v6. Do you see inbound connectivity to home as a
compelling motivation? That would be a tremendous enabler for
application developers.

Stuart: inbound connectivity is the only compelling reason to use v6.
Everything else is currently also available on v4. So, the only only
reason is that it gives me unhindered peer to peer connectivity.

Question from audience (person from Japan): why do you need such long
prefix? /127?

Lorenzo: if you have appoint to point link and you assign a prefix, any
packet will be routed to the middle of the link (ping-pong). There is
a solution to this.


IAB Agenda and Chair Report
IRTF Status Report
IPv4 Depletion and IPv6 Adoption
From IPv4 only to v4/v6 Dual Stack
Post IPv4 "completion"
IPv6 Deployment at Google
Apple IPv6 Experiences