Skip to main content

Minutes for V6OPS at IETF-92
minutes-92-v6ops-1

Meeting Minutes IPv6 Operations (v6ops) WG
Date and time 2015-03-26 14:00
Title Minutes for V6OPS at IETF-92
State Active
Other versions plain text
Last updated 2015-04-09

minutes-92-v6ops-1
Note taker: Chris Grundemann
Jabber: Jason Weil

ÊIPv6 Operations - IETF 92ÊÊÊÊÊÊÊÊÊÊÊÊÊÊ Wednesday 25 March, 13:00

Agenda Bashing
Ê- No bashes

Chairs Mea Culpa, draft-ietf-v6ops-cidr-prefix needs to go to WG Last Call

IPv4 as a service:
Fred B - We're going to look into this
Joel J - Number of possible topics, some may require re-chartering, work in
other groups etc.

draft-ietf-v6ops-design-choices:
*Philip Mathews (Victor K is remote)
Changes -03 to -06 (Honolulu to Dallas)
Narrowed scope to routing-related design choices for dual-stack and IPv6-only
networks Added security considerations, contains pointers (nothing new) Many
document design changes (not substantive) Fred B - Who has read the draft?
[several hands up] Who has issues? [no hands] Philip M - Use of "unnumbered"
was objected to Possible terms offered on mailing list, 6 options on slide
Let's discuss Mike ? - Not unnumbered, anything else, I like #2 PM - what would
the inverse of link-local-only be? FB - The converse would be around the "only"
bit Mike - The interface doesn't have a number, it has an address At least six
people said link-local-only Lorenzo Colletti - why are we talking about this? I
propose sheepskin. Using english only is exclusive FB - sounds like convergence
on #2 link-local-only yes - hum no - almost no hum

draft-ietf-v6ops-pmtud-ecmp-problem
*Joel Jaeggli
is now a wg doc
we went through the entire document
we had some useful commentary
like looking for planets, the more we look the more we see folks working around
this issue (multiple solutions) CloudFlare is one, they've been asked for text
- will rev doc, looking for more inputs from different networks with unique
challenges some problems are not specific to IPv6, may produce work - possibly
in this doc but likely elsewhere FB - mic open no discussion JJ - there will be
one more revision soon, then we can go to last call FB - is this doc ready for
last call after that rev? hum not ready? almost no hum

IPv6 deployment in a developing country, with MAP-T Trials
*Suprita Sah
http://tools.ietf.org/agenda/92/slides/slides-92-v6ops-1.pdf
FB - I invited some talks, Suprita is involved in a deployment in India
they asked APNIC for a large amount of IPv4 to address a billion people, got
1024 addresses she is dealing with a problem that many of us may soon face
Interesting to see what happens in a developing country also specific to IPv4
as a service she is an ISOC fellow to this IETF SS - overview of IPv6
deployment in India (slides) FB - clarification, what does "IPv6 is Enterprise
ready" mean? SS - the backbone / transit network, not towards the edge
[continues slides] Operational considerations http redirection (with an address
literal), MAP-T better than MAP-E. Redirect should happen at SP entry point,
not edge. Ian F - can you clarify the problem, I haven't seen the same, what
architecture? SS - early stages, we're trying many too much content on IPv4
home gateway support a problem, low cost units with IPv6 not in production
MAP-T was not a standard when we started, no longer an issue Mat J - can you
provide a link to more info? SS - in person

JPNE MAP-E deployment
*Akira Nakagawa
http://tools.ietf.org/agenda/92/slides/slides-92-v6ops-2.pdf
Japanese solution is different than other countries, we are not really an ISP
but basically the same IPv6 history in Japan: 2000-2001 leading companies
started but not deployed 2011 NTT East & West started IPv6 on access network
(they don't have a backbone), that's the start for businesses in Japan Many
ISPs use the NTT East/West access network to provide IPv6 (coupled with their
IPv6 backbone) Japan is now at about 5% IPv6 as measured by Akamai Many
Japanese companies are high on the IPv6 measurements list from ISOC Four groups
of network providers in Japan (see slide) NTT E/W with ISPs are majority,
others include telco, cable, and power companies IPv6 deployment rate of NGN
(NTT E/W) - close to 7% rate of second group - KDDI 99% / CTC 64% FB/LH - Do
these customers all use IPv6? AN - yes FB - they have IPv6 CPE at the customer?
AN - yes LC - yes, they do use it, see Akamai and ISOC numbers AN - reading
status from slides FB - are you saying you have to use DPI to do traffic
engineering on a tunnel? AN - yes continues slides Ian F - what protocol are
you using for CPE provisioning? AN - not disclosed Michael ? - Have you had any
complaints about poeple not being able to use protocols other than TCP/UDP AN -
no complaints SS - how do you identify subscribers without logging? LC -
mapping is deterministic with MAP-E can I use ping? FB - can you use protocols
without port numbers? LC - I only care about ping Ole Troan - yes you can,
outbound ping and reply works ?? - so you have two classes of customers, some
that are not behind MAP-E? AN - yes, all new customers are on MAP-E and we have
had no complaints slides continue LC - how many ports do you give? AN -
confidential LC - do you disclose to your customers that they are not being
provided with an IPv4 address? AN - we tell them we provide both we don't tell
anyone about the number of portsÊ FB - most folks wouldn't understand the
description of an IP address and ports anyway AN - continues slides ?? - Are
you working with Japanese content providers to provide AAAAs? AN - we hope more
will soon LC - there are complaints from customers on their support page OT -
any time of address sharing you will have problems MAP can provide plain/legacy
IPv4 service AN - continues slides (summary) FB - your last point could be
summarized as "if you plan to transition, transition helps"? AN - yes

MAP-T and MAP-E deployment in CERNET and China Telecom
*Xing Li
http://tools.ietf.org/agenda/92/slides/slides-92-v6ops-3.pdf
we're using all three MAPs (MAP-E, MAP-T, and MAP-DHCP)
two backbones, CERNET is IPv4 (20years old), CERNET2 is IPv6 (10 years old)
more recently we added translation between the networks, origin of MAP-T
somewhat modified implementation of MAP-T, less CPEs than users [CERNET
deployment slide] Ian F - do you require logging to have traceability for users
behind the multi-user CPE? XL - continues slides (question taken off line)
multiplexing; ratio is number of users per IP, graphs are UDP and TCP lots of
UDP traffic because students are using Google DNS to avoid the Great Firewall
Traffic; about 1k users per IPv4 address China Telecom; joint project, using
DHCPv6 exactly as in draft mentioned in early slide we are using a very cheap
CPE, about $16 openWRT based Use MAP-T by default, but if you see IPv4 options
DF=1 and MF=1, switched automatically to MAP-E. Detected at CPE based on
traffic (DPI) If all users in China are put behind 1000:1 MAP, we can get to
90% penetration with existing IPv4 address space LH - have you done comparison
studies (between T & E) XL - not yet SS - do you need special CPE support to do
the T/E switch? XL - yes SS - was it easy to implement? XL - we wrote our own
code FB - sounds like an experience draft XL - yes a standard is not needed SS
- even at that ratio we can not support enough users ?? - did you have any
experience with heavy data over UDP? XL - yes, we've seen UDP video work no
problem Mukom T - you do checks per-packet, do you have data on the
capapbility/scalability of that check? XL - less than 1% of the packets are
switched to encapsylation there is no performance impact because with
translation we are already looking at every field in the header

FB - we can move short talks forward or talk about IPv4 as a service
conversation LH - were these non I-D talks helpful? hum Meh? almost no hum

Matt ? - I think we'll see dual-stack clients will see better service than IPv4
only LH - we did a panel with measurement results recently, 15% lower latency
on IPv6 vs. IPv4 M? - I meant port exhaustion more than performance LH - IPv6
is a pressure valve for CGN GH - there is an overhead in setting up a binding
in a NAT, that can cause the initial SYN packet to get delayed once a binding
is in place it's faster the hard part is finding that time delay remotely
(affected by too many variables) LH - I'm not convinced its just first SYN GH -
the first SYN is much longer, for me the others are kind of OK LC - Google has
a lot of data on IPv6 performance and all of this is dwarfed by other variables
(peering congestion, etc.) I expect a CGN to work well until it fails,
reliability issue rather than performance perhaps there is bad load balancing
going on, because IPv6 is only 5% of traffic M? - still worried about another
problem; random subsets of things don't load, on reload other things don't load
Dan Lambert? - the delay is coming from software NAT and is milliseconds for
CPE devices ?? - we've done performance studies, IPv6 is worse than IPv4 due to
missing IPv6 content caches JJ - my port overload NAT can overload your port
overload NAT, making lots of API calls can show this LC - how do you see IPv4
port exhaustion; you force... // or you can factor... there's always a spike,
look at the difference in the height of that spike to know how many sessions
are failing

IPv4 as a service
LH - what do you think?
?? - there is already an RFC for ops guidance on DS-Lite
LC - great idea as long as we have authors giving deployment experience have
real deployments (not test, large, etc.) we need more than 100k users on the
tech before we can provide real guidance ?? - will we also give selection
guidance? FB - I don't know that we can gain consensus ?? - there are documents
like this in progress in softwires Eric Cisco - I would like to see the same
topics/structure in each guide FB - I'm going to send an email to the list to
ask what we want covered in that document