[v6ops] draft minutes first session thursday March 31 0900

[Joel Jaeggli <[e-mail]>]

IPv6 Operations - IETF 80
Thursday 31 March, 9:00-11:30

0) Agenda bashing

fred baker –

presents comments on working group process

We're bothered by the amount of time we have available to devote each
presentation.

Drafts will de considered not because they have made the deadlines but
rather because that have archived traction on the mailing list.

Chairs will engage in editorial discretion.

Presentations without a draft behind them, will continue to be brought
to the wg on the basis of relevance.

Hum requested to demonstrate consensus around sentiment.
More postive than negative volume.

1) Some experiences of common hosts' behavior in broken IPv6 networks

http://tools.ietf.org/agenda/80/slides/v6ops-12.pdf

Teemu Savolainen - presenting

going to share experiences with host behavior

Tim Chown - presents rogue ra interaction with happy eyeballs (2nd to
last slide)

Bad ipv6 behabior due to rogue RAs

With no counter-measures, there would have been 250,000 of these rogue Ras.
Mostly related to connection sharing.
Sample period of 376 days.

Dmitri Anipko - With the most recent proposal RFC 3484 bis, 6to4 would
be deprioritized compared to IPv4, so if most rogue RAs are 6to4, no
other solution may be needed?

Simon Perreault – not that simple

SwedeMike (jabber) - removing rogue RA is something any service provider
should do, it's basic stuff. Don't let customers talk L2 to each other.

2) Happy Eyeballs Implementation Report

http://tools.ietf.org/agenda/80/slides/v6ops-17.pdf

Simon Perreault - presenting
Implmentation of happyballs in draft in Erlang

findings:
	global P mechanism in current drafti is broken
	P is dominated by single stack ipv4

solutions:
	only update P for dual stack hosts,
	update P asyncronously,
	do per destination P or do away with P

findings:
do away with useless delays

solutions:
spec says wait lookup collect  but if lookup for ipvX returns no result,
ipvY should start connecting immmediately.

Janos Mohacsi (jabber)- questions to happy-eyeballs: what about DNS
based round-round load-balancing? It is very widely used.

Dan Wing – happy eyeballs works fine with dns load balancing.

Andri Yurshenko – we do parallel attempts with different address families

Jan ker - I don't disagree - why is dns spamming considered out of
scope. think it's out of scope.

Fred Baker – by the way, we do do api's

Janos Mohacsi - Agree with Fred, We should work on API to help proper
behaviour - like happy-eyeball.

3) Experimental Observations on Dual Stack Service Performance

http://tools.ietf.org/agenda/80/slides/v6ops-1.pdf

Geoff Huston -

looking at the problem from the side of the server

When you look at the world from that vantage point of how much does a
server see, you see a huge amount of capability. You have new experiment
every time it runs.

V6-only test is using ipv6 lteral e.g. no dns

full blown tcpdump along with typical server logs


Dual stack failures are interesting
(e.g. Hosts that deal fine with v6 or v4 only resources but not dual stack)

The internet is remarking heterogeneous not homogenious, apnic site
users about 5% will prefer v6 on a more popular site it's more like .02%.

V6only is 4%
why are there 20x more folks that could use v6 but don't use it

SwedeMike (jabber) -
6to4 is enabled by default if you have a GUA on windows vista/7
but they don't prefer it

geoff -
If you prefer v6 in autotunneling things get pretty rough folk coming in
on v6 unicast seem to do so at about the same rate (speed) as ipv4

The penatly for 6to4 is around 1.2 seconds, teredo setup is at least 1rtt

As part of the experiment tried to mitigate 6to4 variability by putting
v6 relay in the server

Measure the tcp-3way tunnel setup penalty at 150ms average

If you think that's bad lets look at teredo
if the only interface you have is teredo it will not retrieve a AAAA
, therefore only exercised for literal

30% of clients can pull down the object using terredo, an imense
capacity for v6

distribution of setup time, seems to take around 2/3 of a second to setup
peaks at 2 seconds and 3 seonds tunnel rtt cost is about 300ms
some clients get away with almost no added cost.

If you're on unicast v6 be happy and smile, if you're on tunneled v6
turn it off it's

dual stack failure .6%,  we're not sure why.
number is high but unreliable.

Connections failure

How many folk can send me a syn but not an ack

Failure rates for unicast v6 are 2-4%

terredo failures = 35%

12-24% of 6to4 failure due to protocol 41 filtering

38% of terredo fail due to icmp filtering, you also don't like outgoing
udp so ice/stun/turn probably don't work either.

If you want to run v6 tunneling today don't.

help us, see url labs.apnic.net

tore anderson (jabber) -
Regarding 6to4 relay congestion being unlikely due to the low levels of
6to4 traffic: I understand that most of the relayed 6to4 traffic is
actually BitTorrent traffic that is rendezvousing with Teredo. This is
of course invisible from the web server vantage point, but it might
anyway cause congestion on the same 6to4 (and Teredo) relays that also
handle the web server traffic that are actually observed in the experiments.

Simon Leinen (jabber) -
Tore: We have more than 100 Mb/s on our 6to4 relay right now; looks like
most of this is indeed BitTorrent.

Dave Thaler (jabber) -
p2p works much better than non-native to native (which is actually
related to why Windows doesn't do AAAA queries if it just has Teredo, as
Fred said... by design)

Simon P -
should it be depricated

geoff -
killed
simon p:
would it be better to turn it (relays) off?
Igor Gashinsky -
killing relay isn't effective kill os.
igor G -
Counting dns failure rate is atrocious
Geoff H -
this is tcp failure counting so the dns failures don't show up
Rajev -
If we look at the data from the weekend do we draw different concusions
about tunnel performance?
Geoff H -
We don't consider 12% failure as drammatically better than 20% it's just
bad.
Lorenzo C - The results match what we see, we've been looking at the
network, we have certain large isps with peaks around 3-4%
Geoff -
would that we had more data, we seem to have tiny aperatures. badness
clumps.

the time for automatic tunneling has really passed some operating
systems and home routers should turn it on by default we'll discuss this
later but I think that a statement from this body supported by this data
would be helpful.

Dmitry Anipko (jabber) -
Comment to Lorentzo: connection from automatic tunneling to native IPv6
is not preferred by default per RFC 3484

 geoff h-
we can't hop over brokeness in the isps netowrk

lorenzo -
don't try and make pigs fly

Tony Hain -
 it is insane to insist on deploying a transition technology half-ass,
then blame it for failures..

Mark T - qualify statement, in a controlled environment we can hop over
v4 netowrks

Tony Hain -  if the content providers deployed 6to4 on their end the
path would be exactly the same as IPv4 door-to-door.

4) Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts

http://tools.ietf.org/agenda/80/slides/v6ops-21.pptx

14-Mar-11, <draft-ietf-v6ops-happy-eyeballs-01.txt>

Andrew Yourtchenko -

changes
add srv records section
added mif reference
added debugstrawman

todo
need more implmentations
address hysteris problem
need pluggable name based connect api...
write a seperate draft for that? Where to take it?

Fred B-
The INT area.

Jari Arko -
yes

Dave Thaler -
Microsoft's pm's went to content providers, there is level of concern
about multiple simulatnious connections and pontetially large number of
resets.

major agreement that problem needs to be solved. Can we do a better job
about which one to try first?

Maybe p could actually be fairly large if you had a good guess.

Mark Andrews -
happy eyeballs is a really generic problem with multihomed machines

Janos Mohacsi -
Agree with Dave Thaler: Some providers blacklisting clients with high
syn and rst rates

Fred B -
some sort of memory about specifc addresses or prefixes

Igor -
I'm going to disagree with that sorry, as on operator I'll take the pain
from happy eyeballs over the pain from not having happy eyeballs.

Andrew -
Feedback needs to be incorporated into the list

Janos Mohacsi (jabber) -
Agree with Simon Leinen. That is the correct solution as I have written
earlier on v6ops mailing lists: RFC 3484(bis) can be used as a hint what
makes sense and what is not.

Dave Thaler -
@simon: be careful, you need to it converge fast.  starting with 0
knowledge for every s*d would be bad.  That was my point about sharing
knowledge so you guess right the first time almost always

danwing -
I disagree with Thaler, because a Happy Eyeballs user will _not_  be
sending a lot of SYNs and RSTs.  "P" prevents them from doing that.
It's only the first connection that would be in parallel.  Subsequent
connections will continue to trend towards IPv6 (if it's working) or
towards IPv4 (if it's working).  And content providers have one, and
only one primary job in life:  deliver content.  Happy Eyeballs is
aligned with that goal.  Which Igor re-inforced at the mic.


5) IPv6 Multihoming without Network Address Translation

http://tools.ietf.org/agenda/80/slides/v6ops-10.ppt

6-Dec-10, <draft-ietf-v6ops-multihoming-without-nat66-00.txt>

presenter unknown -

next steps?

Fred B -
Need feedback

6) Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement
and Proposed Mitigations

 http://tools.ietf.org/agenda/80/slides/v6ops-4.ppt

14-Mar-11, <draft-ietf-v6ops-tunnel-loops-05.txt>

Fred Templin-

problem

mitigations

For zeroconf dynmic routing, we've come up with  proposal that meets
these requirements - out of scope for this group.

Fred B -
Ron asked us to do another parallel last call on WG (on the revised
draft) while an ietf last call is carried out.

adrew yourtchenko  -
Well, on approach  keep decrimenting the hopcount  if it gets below a
certain threshold, then throw it out.

7) IPv6 in 3GPP Evolved Packet System

http://tools.ietf.org/html/draft-korhonen-v6ops-3gpp-eps

9-Feb-11, <draft-korhonen-v6ops-3gpp-eps-06.txt>

j korhonen -

updates since ietf79
work to make the draft more opinion neutral
add operational aspects of v6only networks
added ipv6 address configuration clarifications
add ipv6 roaming conisderations
adder inter-rat handovers

Guillaume Leclanche (jabber) -
Problem with v6 in the mobile world is that implementations are way
behind the 3gpp releases.
 Which are themselves way behind IETF specs.

J korhonen -
needs 3316 recommendations

Tina Tsou -
about epc, is it addressed here?

Fred -
Call the question,

hum (is this a working group document)

Joel J -
hum in affirmative not noted opposition.

Fred -

Hum (in favor of wglc)

Joel J -
hum in affirmative of WGLC

8) NAT64-CPE Mode Operation for Opening Residential Service

http://tools.ietf.org/html/draft-chen-v6ops-nat64-cpe

14-Mar-11, <draft-chen-v6ops-nat64-cpe-01.txt>

Gang Chen -

uses
requirements
changes since 79

pcp upnp and nant-pmp are recomended with nat64cpe

Fred B -
we'd work on the requirements, the solution would be behave

Gang C -
 we're generating requirepments

Fred B-
we'll have to take the adoption question to the list.

dan wing -
First half is a draft for v6ops, second half is a scenario in behave.

Hui Deng - ?

9) Experience from NAT64 applications

http://tools.ietf.org/agenda/80/slides/v6ops-18.ppt

7-Mar-11, <draft-tan-v6ops-nat64-experiences-00.txt>

Cathy -

test enviroment description
scenarios
results

dan wing -
thanks for reasearch.
It's easy to draw the wrong conclusion e.g. everyone has breathed air
has died

Some other examples are caused by ipv4 address sharing

I realize this is the first generation of this analysis. in behave we
have cgnat in nat444 analysis.

We need to uplevel this to the spefic problems in nat65 that make this
harder and or which can be addressed.

Fred B -
feedback and testing on the algorithm that behave has just produced

Dan Wing -
Failure needs to be traced back to a root cause, where can we help.

jari arko -
thank you this is important work

Also want to emphasis on finding the root cause - different failure
modes, some are in application there are some problems with the content,
third class  where there's something wrong with the nat64 or natpt device.

Simon Perreault (jabber) -
FYI: We're running a NAT64 experiment right now (SSID: ietf-nat64) with
a survey to gather your experiences. Please try it.

hui deng -
We do need to analyis the issues that those applciations really have

jari -
it's going ot be a long task

tina tsou? -
two comments, mainly affected by the p2p applications? who supports
nat64 couldn't find it on the market

 jari - there are vendors with this product already  so do nat64 testing

Janos Mohacsi (jabber) -
to testers: http://ecdysis.viagenie.ca/

10) Comcast IPv6 Experiences
(no slides on agenda)

7-Mar-11, <draft-jjmb-v6ops-comcast-ipv6-experiences-00.txt>

JOHN Brzozowski -

trials starting in jan 2010

making determination of need based on volume

Deployed
6rdbr
	performance base on proximity
	geolocation potentially impacted
	limited support/manual configuartion
native dual stack
	l2 delivery
	geographically liimited trial
backoffice support project started 4-5 years ago

wes george -
6to4 world ipv6 day, 6to4 relays what will happen, we'll shut it off? or
there are some relay out there that make it ok.

John B -

it's (6to4 traffic) gonna go somehwere

Fred -
could nullroute the anycast address

Wes G -
assuming the client behaves well in that case

John B -
 trying to suck less, 6to4 relays

fred t –
use of isatap?

John B-
we use it internally, our focus is on the native aspect.

dave thaler -
In 6to4 trials
did you run into issues casued by broken relays

John B -
Return path is still the problem

11) World IPv6 Day Call to Arms
http://tools.ietf.org/agenda/80/slides/v6ops-9.pdf

14-Mar-11, <draft-chown-v6ops-call-to-arms-01.txt>

tim chown -

world ipv6 day call to arms
aims
issues
	unmanaged tunnels
	pmtu
	connection timeouts
next steps

do we influence the experiement?

Janos M (jabber) -
I support tims draft

Mark A -
we should harden this in advance of june

 wes george -
we need to stop looking at htis as an experiment it's testing for primetime
not influencing it is wrong headed

Janos Mohacsi (jabber) -
about 6to4: discourage for this experiment - 6to4 should be used as a
interim solution - not what IPv6 should be used.

Tim C -
change

Fred B -
value is 2 fold it's y2k, it's also marketing

dave thaler -
yes we want to influence the experiment

Igor G -
I hate to say this but the expierment is to break the users and see how
many get fixed the meaningfully data is what happens

Lorenzo C-
lets not try to demonstrate that we can do this well but rather
recognize what problems we have and make them better

Somebody may decide to leave this stuff on

Igor G-
Whatever hacks you deploy please leave them in place
2:36:55 AM jhf: in case they have proven to work well

Mark T - deployment on v6 day as though it were more than one day
capture that as prime directive

Dave Thaler - mark said what I meant... we want people to think and do
what they would do if this were longer term, and learn what happens and
get experience

Lorenzo -
More relay won't help or hinder them

and if you call that influencing the experiment, then we should.

----
Done