[v6ops] draft minutes ietf 81, 3 meetings...

Joel Jaeggli <joelja@bogus.com> Tue, 02 August 2011 17:24 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD1611E807F for <v6ops@ietfa.amsl.com>; Tue, 2 Aug 2011 10:24:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.35
X-Spam-Level:
X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITkUXyNIFjl3 for <v6ops@ietfa.amsl.com>; Tue, 2 Aug 2011 10:24:11 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDF111E8098 for <v6ops@ietf.org>; Tue, 2 Aug 2011 10:24:08 -0700 (PDT)
Received: from [10.101.144.52] (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p72HOG2E068571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <v6ops@ietf.org>; Tue, 2 Aug 2011 17:24:16 GMT (envelope-from joelja@bogus.com)
From: Joel Jaeggli <joelja@bogus.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 02 Aug 2011 10:24:11 -0700
Message-Id: <D6008BA7-7B05-49C2-B40D-DCD92A0FAF39@bogus.com>
To: IPv6 Operations <v6ops@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 02 Aug 2011 17:24:17 +0000 (UTC)
Subject: [v6ops] draft minutes ietf 81, 3 meetings...
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2011 17:24:12 -0000

There were at least 2 note-takers plus 2 people scribing on jabber at various times. I'm am deeply appreciative of the contribution to making these notes useful.

IETF 81 
V6OPS WG Minutes

-------------------------------

--Tuesday July 26 0900-1130 EDT
Approximately 200 participants

Fred Baker - Introduction
     The meeting is divided into two sections 
     	 1. World ipv6 day
	 2. Old Business

* Presentation - World IPV6 Day Measurement results - Keranen
	     http://tools.ietf.org/agenda/81/slides/v6ops-0.pdf
	     http://tools.ietf.org/html/draft-keranen-ipv6day-measurements

* Presentations - Microsoft Measurement report - Chris Palmer
	      http://tools.ietf.org/agenda/81/slides/v6ops-1.pptx

the sad graph, basically half a percent of th euser base came in via
v6, 7% of those folks were windows xp which is surprising becuase you
have to turn it on. as far as method, 91% native 8% 6to4 and 1%
teredo.

CDN's delivered, really at the last minute but they were there.

It's hard to say given the usage that we've validated this at scale.

Ralph D - Clarification Question ipv6 geolocation is it
unavailable or is it incorrect.

Chris - We use third parties and they're lacking the data.

? - What would it take from miscrosofts perspective to roll a patch to
enable windows XP

Chris P - That's something we've been generically thinking about but
there's only a 1000 days of Windows XP left.

Lorenzo C - one of the things you achieved with this is the removal of
fear. How do you lock in those gains? if you do nothing the fear will
come back.

John B - We see duplicate DUID when windows devices do DHCPv6, which
creates and operational complication.

Chris P - Stacks changes are coming in Sept.

Eric Kline - Will IE get ahppy eyeballs or fast fallback so it can
join the other browsers? 

Chris P - So things like happy eyeballs are useful but fuzy towards
the no. We're inclined to make changes to 3484.

Dan W - Hey your v6 is broken is is not generic to the whole internet,
it may work in your office or home, so a solution has to have scope.

* Presentations - Checkpoint's World IPv6 Day Experience - Bob hinden
	      http://tools.ietf.org/agenda/81/slides/v6ops-3.pdf

Mark T - In our experience there are a lot of things we could just
leave up afterwards, yet there is a lot of legacy stuff that has to be
validated.

Bob H - By doing this deployment exercise we're now having
conversations about internal deployment now that the IT team feels a
lot more comfortable and turns out to have not been that hard.

* Presentation - World IPv6 Day, What did we learn (Ripe measurement report) - Bert Wijnen 
	     http://tools.ietf.org/agenda/81/slides/v6ops-4.pdf

Bert W - Ripe had about 40 measurement points from which to observe
world ipv6 day. 

Looking at DNS queries, 2 days before, negative cache TTL dropped for
several participants.

The internet is is a collection of internets connected to each
other. Some of our vantage points revealed partitioning which was
confirmed with further discussion.

when monitoring performance ipv4 vs ipv6 for source destination pairs,
v4 was a little better, but very close however.

Alain D - Did you monitor the propigation of /48 prefixes , there are
rumors of edge providers still filtering.

Joel J - We advertise /48  prefixes and these days, we see them
basically everywhere we can see with routeviews.

Hue Deng - use of nat 64 for services can you detect that in your
data?

Joel J - Question everyone uses a load-balancer at scale, what are you
trying to find?

Alain D - With nat64 in front of the a server we have lost the identity
of the user.  

* Presentation - IPv6 day operators report (hurricane electric) - Martin Levy
	     http://tools.ietf.org/agenda/81/slides/v6ops-19.pdf

Only port 80/443 traffic volume changed on IPv6 day. We credit much of
this to youtube.

Teredo tunnels require that the tunnel-end point return an icmp6 ping.

About 11% of ASes are IPv6 enabled, if you count adjacencies, by the
time that you get to 7 adjacencies about 50% of those players are ipv6
enabled.

Geoff H - Your commnetary about Teredo isn't gelling for me, at the
client side the ICMP is in UDP, the modified stun protocol in teredo
guesses wrong about 37% of the time with the NAT binding. 

* Presentation - Comcast expereince with ipv6 deployment - John Browsowki
	     http://tools.ietf.org/agenda/81/slides/v6ops-20.pdf

Traffic increased notably during world ipv6 day.

An additional trial is being deployed (DS-Lite)

Native dual stack validated, preparing for production deployment.

We took Jason Fesler's IPv6 testing code and did some 30,000 tests
with end users, found some users that were potentially impacted.

Hue D - How is your backoffice deployment supporting IPv6? 

John B - We've been working on it for about 6 years. The edge of the
broadband network is where the effort is.

Lee H - I thank you John because we started three years ago which
means things have gone much faster. 

Chris P - Do you have visibility into  household customers with
gateways that don't support V6? 

John B - That vast majority, when we enable it in the broadband
network we can tall people hey guys you need to upgrade. 

Chris P - my concern is that maybe if we're lucky we can reach 1 in 4
households.

Lorenzo C - As a customer V6 is great and it works as well as ipv4. If
you went all out how long would it take you to bring V6 to 1% of your
customers? 

John B - 1% is doable pretty easy thequestion is more like the 90% number.

Fred Baker - Status report World IPv6 day call to arms
     http://tools.ietf.org/html/draft-chown-v6ops-call-to-arms

It doesn't have a lot of value as an RFC so Tim will let it lapse but
the info will go into some other drafts.
     
* Presentation - Happyeyeballs implementation report - Dan Wing
	     http://tools.ietf.org/agenda/81/slides/v6ops-5.pptx
	     http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs

After discussion on the list, instead of describing the algorithm we
decided to describe requirements. There are two versions stateless,
e.g. chrome or firefox vs stateful Algorithms.

Chris P - I think the direction is fantastic, requirements are good.

* Presentation - IPv6 DNS Whitelisting - Jason Livingood
	     http://tools.ietf.org/agenda/81/slides/v6ops-6.pptx
	     http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications

Lots of feedback from the IESG, generating version 3-6.

We talked to implmentors, and it needs another rev, to make it
acceptable to a swap of the community. 

Wes G -  When this approach was first tried manual was the only
approach. 

Lorenzo C - When we started this it was because we had no
alternative. We removed ourselves from the discussion because we
thought it was a critique of us. It's possible that we can produce a
document that we can accept.

Focus on intent and consequences in this draft. 

Fred B - Is there something (a taxonomy of GTM/GSLB) that we
should take to DNSOP?

Fred Baker - Response to Appeal on 6to4 to historic
     http://tools.ietf.org/agenda/81/slides/v6ops-24.pptx
     http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic

Keith M - I'm convinced that you did due dilligence with respect to wg
consensus. 

Fred B - It is worth noting that the draft did have some impact (with
vendors).

New business

* Presentation - RFC for IPv6 IP identification field (header) - Mike Ackerman
	     http://tools.ietf.org/agenda/81/slides/v6ops-7.ppt
	     http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header

Fred B - Question for the group, do you use the IPID in ipv4? (no
respondants other than presenters)

Weg G - We use it all the time? I've never heard of it...

Francis D - it's potentially a covert channel, also why not use the
fregmentation header?

Bob H - We diefintently want to hear if this is useful. I don't know
who puts this header in the packet?

Nalini ? - The host clearly

Andrei Y - typical use case for this header would be to see if a
middle box is modifying the packet. 

Fred B - What I'm out of this discussion is that the application isn't
a bad one, it could be simulated in a fregment.

Fred Baker - Meeting complete, go to Lunch


-------------------------------
 
-- Thursday July 28 1520-1720 EDT
Approximately 200 participants

* Presentation - Stateless 4Via6 - Wojec Dec
	     http://tools.ietf.org/agenda/81/slides/v6ops-8.ppt
	     http://tools.ietf.org/html/draft-dec-stateless-4v6

4v6 index provides enough information to compute an ipv4 address and
port index.

Example scenario - A CPE, inside it has a port contrained nat44
implmentation along with the 4v6 function. inside the cpe we nat the
source ip to a public v4 address and port rnage provided by the v6
address encapsulated and sent to the 4v6 gateway where it is sent on
the internet.

Alternative modes of operation, mapped, vs translation. Translation
has signficantly less impact in the 3gpp case.

Oel T - Wanted to ste for the minutes that there isn't any practical
difference between encapsulation ad double translation.

Wojek D - We didn't get to have the discussion in softwires we belive
that V6OPS is the best place to capture the operational issues.

Hue D - would like less impact

? Shima - Going to be a work item for softwires.

Mark T - The vast majority of both operations are the same, the
question is do we compress the headers out or not. I support the
minimal effort which is encapsulation.

Alain D - This will be done at the interim metting in sept.

Jari A - we should put them in the same place (softwire) rather than
split them all over the place.

Sing Y (cernet) - Sometimes we deploy single translation sometimes
double, we haven't found many corner case where one works and the
other doesn't.

Fred B - Would suggest that people here read the draft, and comment to
softwire where the work will be done.

Dave T - the difference between tunneling and translation is very
small and it would be an odd division to put those in two places.

* Presentation - advanced requirements for cpe routers - Ole Troan
	     http://tools.ietf.org/agenda/81/slides/v6ops-9.pdf
	     http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-bis

Request from homenet to move the lan side of this document to the
homenet wg. thus the document will be split in wan requirements vs
lan side which will go there.

Options
	give up on the document
	move to softwires (the ds-lite part) 
	resubmitt 6204 with ds-lite and 6rd requirements
	continue.

Barbara S - I like 6204 option or option 4

Ole T - include requirement for PCP?

Alain D - PCP has been through two WG last calls

Mark T - 6rd and DS-lite and PCP and making them come up and behave
well together, that work is already here.

Barbara S - Inclusion of PCP will start the question of do we also
include UPnP

Lorenzo C - what 6204 and homenet are doing is a relatively
partitionable problem.

Fred B - Question for Barbara, does this start here or in the BBF
(broadband forum)

Barbara S - Start them whereever someone is referencing PCP

Hemant S - Lan side requirements are where we have real urgency from
operators.

Fred B - unless homenet feels badly them my expression would be to go
for the thing with the nearest completion.

Erik K - we need to have the cpe vendors be able to build this early
next year.

Jari A - we should publish what we have, if there's falky stuff we
should pull it.

Lorenzo C - In a closer reading of some of the lan side stuff dhcp
will definitly hurt homenet work.

* Presentation - IPv6 RA-Guard  Evasion - Aurturo Servin
	     http://tools.ietf.org/html/draft-gont-v6ops-ra-guard-evasion
	     http://tools.ietf.org/agenda/81/slides/v6ops-11.pdf

Fred B - so you made this presentation in 6man, what was the upshot?

Aurturo - Was asking for acceptance becaue it's updates 6105, in v6ops
case it's documentation of the issue and the operational solutions.

Fernando G - Ra-guard is/was an infomational document produced in
v6ops not 6man.

Ron B - We would be stepping on the charter of 6Man

Joel J - (outside of the problem statement)

Fred B - We'll talk with Bob and Brian but it seems like the work can
be done in 6man.

* Presentation - IPv6 Practices on China Mobile  IP Network - Chen Gun 
	     http://tools.ietf.org/html/draft-chen-v6ops-ipv6-bearer-network-trials
	     http://tools.ietf.org/agenda/81/slides/v6ops-16.ppt

Chris P - empathize strongly, I think it's great but I have a
question are you drving load from your user's against this?

Chen G - we have a plan for that, it's a lab exercise.

Hue D - we have a national project that will deploy later this year.

* Presentation - NAT64 CPE Operation Usages and Requirements - Chen Gun 
	     http://tools.ietf.org/agenda/81/slides/v6ops-25.ppt
	     http://tools.ietf.org/html/draft-chen-v6ops-nat64-cpe

Fred B - If the other draft is covering the same material at least
they could be merged.

* Presentation - A Discard prefix for IPv6 - Dave Freedman 
	     http://tools.ietf.org/html/draft-hilliard-v6ops-ipv6-discard-prefix
	     http://tools.ietf.org/agenda/81/slides/v6ops-12.pdf

Dave Freeman - Where should the prefix be from?
     documentation range?
     cute hex?
     more than one address?
     Global Unicast?

Hard-Wired discard prefix is a standards track item.

Nick H - There are concievable situations where you might want to leak
this prefix e.g. to downstreams for DOS analysis etc (Warren K,
Lorenzo C dispute this)

Rob ? - We don't have a BCP for implementation

Joel J - as one of the coauthor's on the ipv4 (RTBH BCP) the ipv4 one
would be virtually identical.

Fred - hearing a fair amount of support (hum) in favor no opposed 
short prefix (e.g. /64) vs /128 
      wg prefernce for /64
This is an arguement for  BCP,
Lets take this to a working group last call and move it ahead.

* Presentation - DHCPv6 Prefix delegation as IPv6 Migration Tool in
	     mobile netoworks - behcet Sarikaya
	     http://tools.ietf.org/agenda/81/slides/v6ops-13.pptx
	     http://tools.ietf.org/html/draft-sarikaya-v6ops-prefix-delegation

Fred B - WG do you want to see this as a WG item?
(show of hands shows no strong support each way)

Nor support (for or against) individal submission

Fred Baker - meeting over

-------------------------------

Friday July 29 1300-1500 EDT 
Approximately 80 participants

* Presentation - IPv6 Address accountability Considerations - Tim
  	       Chown 
  	       http://tools.ietf.org/agenda/81/slides/v6ops-29.pdf
  	       http://tools.ietf.org/html/draft-chown-v6ops-address-accountability

Tim C - At the moment people in ipv4 have a reasonable task of
providing address accountability in v6, things like privacy addresses
make that harder.

Dave T - What do you mean by accountability

Tim C - either a hardward port or 802.1x giving you a binding between
port and ip address correlation between ip4 arp and ipv6 nd tables and
polling rapidly enough that you know your data is relevant,
alternatively record all nd traffic on the link.

Fred B - Zigbee has Pana 

Unkown (Back mic) - Use Savi

Tim C - Currently documents say logging with Savi should only log
potential spoofing events, Logging all mapping data would be required.

Fred B - as a Savi author switches in general have places where they
log all sorts of things.

James W - Shouldn't this rightfully be taken up in NOG organizations,
One person's accountability is another Persons Pen Register.

Wes G - The privacy concerns are something that should be included in
the document.

* Presentation - Operational Neighbor Discovery problem and
  	       enchancements - Joel Jaeggli
	       http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance
	       http://tools.ietf.org/agenda/81/slides/v6ops-21.pdf

Joel - 6Man owns the solutions, V6ops feedback on whether there's a
problem or not is helpful.

Ole T - What's the relationship of this work to 6 lowpan nd 
Joel J - Don't know haven't explored that.

Lorenzo C - Propose splitting the draft into operational guidance vs
protocol changes.

Fred B - Are address scans a problem? 

If this draft is split would the working group take the operational
and implementation details (consensus, no opposition)

* Presentation - Implementing AplusP in the provider's IPv6 only
  	       network - X Deng
  	       http://tools.ietf.org/html/draft-deng-v6ops-aplusp-experiment-results
	       http://tools.ietf.org/agenda/81/slides/v6ops-14.ppt

X Deng - implemented both port-range and scatter port a+p 

Fred B - So this is the Demo you showed in the terminal room?

X Deng - Yeah
What Breaks? UPNP clients. 

Marshall E / Dan W - Is there a security implication to the mask of
ports? If I'm running a Kaminsky Style attack I can guess your next port.

Stuart C - Lot of focus on making UPNP 1.0 work, it never will,
you have to throw it out and start again hence IGD 2.0

* Presentation - Rapid Transition of IPv4 contents to be IPv6
  	       accessible - Q Sunq
	       http://tools.ietf.org/html/draft-sunq-v6ops-contents-transition
	       http://tools.ietf.org/agenda/81/slides/v6ops-27.pptx

Wes G - In the case where you turn on content providers, they
need to do that on their own edge. Has this show us a practical
application worth replicating or is this a proprietary one-off worth
documenting. 

Dan W - if the consensus in the room is that nat64 is inappropiate
in front of an ip4-only server because of a loss of the IPv6 source
address, then v6ops would benifit from documenting that as a not
recomended deplyoment.

Lorenzo C / Jason W - There's a disparity where content is ahead
of access. Access provders are currently working on that.


Fred Baker - Meeting adjourned