[v6ops] draft minutes second session Thursday 31 March, 17:40-19:40

[Joel Jaeggli <[e-mail]>]

Thursday 31 March, 17:40-19:40
12) Advisory Guidelines for 6to4 Deployment

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

11-Mar-11, <draft-carpenter-v6ops-6to4-teredo-advisory-03.txt>

brian capenter -

trying to put toothpaste back in the tube
people having been complaining about
this is an attempt to do something

was not deisnged as an unmanaged solution

filtering of protocol 41 is the main reason for these failures

summary of issues

advice to vendors

do not enable 6to4 by default

do not do it from rfc1918 addresses (bug)

return destination unreachable if you can't do v6

don't break protocol 41

advice to transit ISPs

 even if you hate 6to4 you can only make things better if you run a router

 as a content provider running a local relay will definently help if you
plan to support ipv6

randy B -
7th of june is too late

tore (jabber)-
The "defend against rogue RA" advice is equally important for ISPs that
do not support IPV6

tim chown -
Recommendation internet connection sharing should use a lower default
router preference

SwedeMike (jabber) -
tore: yes. if you don't support ipv6, just block all 86dd between your
customers

brian -
consider running them(relays)

 wes george -
let me respond to that end hosts are going to do whatever

13) 6to4 Provider Managed Tunnels

13-Mar-11, <draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02.txt>

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

Victor k -

level set we still belive native v6 is sthe best solution

6to4 is is challanging especially when covered by carrier grade nat

cgnet is already out there.

There are legitimate uses of non-rfc1918 addresses behind cgnat.

As noted it's low cost and can run on existing relays.

Has been test since Beijing

p2p with another 6to4 device doesn't work. Referalls to the address are
challanging

when behind the CGN it's either broken or it's not.

Works for the use case we defined.

Ole troan -
still a symetric nat


14) Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to
Historic status

9-Mar-11, <draft-troan-v6ops-6to4-to-historic-01.txt>

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

ole troan -

Summary, makes 3056 and and 3068 historic.

What is historic?

If it is superceeded or made obsolete by another specification or no
longer used.

We are pretty sure that protocol 42 is not going through a lot firewalls.

We are saying that this is a technology that the ietf will not evolve
further.

Wes george – we have to struggle with the definition of historic

it's good to differentiate beween turning it off in the hosts vs turning
it off in the relays

fred b – precent for a widely used protocol  being taken to historic,
ripv1. Every cpe supported ripv1. Ripv1 had no context for cidr.

That was not to say don't use it.

Brian C -

we should do both e.g. you can consider victor's and ole's draft at the
same time.

Ole t -

I need this document for our linksys people

Mark Handley  -

you stole my anecdote

another certification body says do this ietf thing

dave t -

same thing as brian

second point I likened it to two issues try to depricate different rfcs
is less jsutification for 6to4 bc's presentations covered potential
jsutification

regarding 3484, if it changes that as well then the title needs to
reflect it.

Primary problem is for relays, what is fairly easy to do without code
changes is to tell it not to use the relay.

Tom chown -
what do we use behind a host instead of 6to4 for connection sharing

Igor G –

guidance as to how to make it better, and oh by the way don't use it.

because it's protocol 41 and it's everywhere p2p and relay are both broken

Mikael A (jabber) -

for me, 6to4 should go away asap, both the relay and the direct version

jordi M -

question of making the protocol historic vs the question of making
anycast histoic.

Ole T -
have list of drafts for other protocols

this draft says depricate the whole thing

Lorenzo C -
I hate to think of anything else going through it if it's this hard for us.

Igor g – depricate 3068

geoff h -
there are many ways that 6to4 can fail in the mehtodology I used,
failures due to relays are not tested.

The only failure I was seeing was really narrowed down to protocol 41

I can't measure the failures that don't get to me.

Brian c -

I don't believe that 3056 is broken, nobody deployed it.

It's true that what microsoft did is that when folks use dns to
rendezvous then you don't see much teredo.

Tore A (jabber) -

 you will get 3056 between two end sites when the end
users both have CPEs that implement it by default and send out RAs by
default. and what happens then? the end hosts have 1) an IPv6 address -
the 6to4 one, and 2) a default router - the CPE. this is a recipe for
end-user brokenness.
Geoff – whatver is going on in terredo the failure rate is right up there.

Mark H -
if we do something less than depricate everything we leave the door
open, then disabled by default needs to also be in there.

Igor G -
in that spirit optional should be considered harmful and ill advised.

James Woodyatt (jabber) -
that would be going to far

erik kline -
+1 for depricating 3068

consider whether we want to save 2002 in global scope

dave t (jabber)-
without a relay 2002 is the same as ula

erik kline -

what is the status of ipv6 nat, 6pt is what I would be thinking of

fred b -

calling the question,

this is my summary

is this the recommedation we want to make? Do you believe that in
general this is the way that we want to go.

Hum, generally in favor, some opposition noted...

for brian's draft yes

for ole's draft yes

for victors draft no

fred -

victors draft could proceed as an indivual submission

lorenzo c -
ipv6 day is not about deployment, we can't deploy it in two months

it's about fiding problems

igor g – if the drafts come out first it's useful ammunition

mark handley – the bullets are nice and should be captured in one of the
documents

tony hain (jabber) -

this decision should not be driven by intentional deployment in  way
that breaks it (6to4)


15) IPv6 anycast based feedback data aggregation
7-Mar-11, <draft-kanizsai-v6ops-anycast-data-aggregation-00.txt>

(not presented)

16) Scalability issues in CGN Address Sharing
LAFT6: Lightweight address family transition for IPv6
14-Mar-11, <draft-sun-v6ops-laft6-01.txt>
Considerations for Stateless Translation (IVI/dIVI) in Large SP Network
6-Mar-11, <draft-sunq-v6ops-ivi-sp-02.txt>

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

? -

experience developed on recommendations from softwire.

Communications scenarios, two major first ipv4-ipv4  for most current
applications and ipv6 – ipv4 for p2p

cgn brings a lot of cost

enumeration of changes required by solution

address consumption by solution

punchline ipv4 address sharing is complex

roberta Maglione -
need a more scalable address sharing mechanism

Randy b -
shes correct dslite can easily go that path

Basaraj P -
where do you se stateless getting mediated

Shin Miazawa –
pros and cons of stateless divi it is still dificult to identify behavior

nat 444 can do static mappings

mark h – I'm a big fan of the stateless mechanisms, when they're
possible, they're not always possible.

Fred -
would be nice to capture all this information in an internet
draft-carpenter-v6ops

Jari arko -
in the int area we discussed stateless and aggreed to work on stateless
(in softwire)

Roberta M –
motivation document in softwire is called stateless solutions

mark h -
not supposed to specify the actual bits, architeturaly both solutions
are a tunnel divi or 4rd

jari a -
what mark said

tina t -
reduce the burden fo stateful translation

fred -

softwire is the a place to have the future discussion.

17) Multicast Transition to IPv6 Only in Broadband Deployments
14-Mar-11, <draft-tsou-v6ops-multicast-transition-v6only-01.txt>

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

tina tsuo -

presentation

end

comments?

thanks

18) Solution Model of Source Address Tracing for Carrier Grade NAT (CGN)
16-Feb-11, <draft-zhang-v6ops-cgn-source-trace-00.txt>

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

Dong zang -

problem is the identification of end user through nat translation

hostid is another potential example.

Shin M -
this is a cgn requirement and we are working that.

Fred B-
It can't be done here it's a protocol

James W (jabber) – ietf policy wiretapping (28040 is relevant to this
draft).

Fred B -
At a minimum if people do find this useful the question is where to do it.

Chris M -

we have lots of methodoigies to address this.

Tina T -
in the cgn enviroment this one connection may belong to different users

as to the question fo whether this work is useful, I think it is useful
and needed.

In the case of a cgn it identifies thousands of subscribers.

There are other use cases

roberta m -
this is a useful we need traceback, other use cases in the internet area.

Shin M -
this is a useful but not here, we have discussed it in softwire

Randy B -
you know who the you who wants to know who I am is (leo)

Dan wing (jabber) -
the draft is inaedquate to meet the needs of law enforcement

Joel j – (channeling james w at the mic)

2804 applies in that it is out of scope to consider the law enforcement
requirements

igor g -
while I'm not advocating this randy it does provide a more fine grained
method.

19) Advanced Requirements for IPv6 Customer Edge Routers

5-Mar-11, <draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt>

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

lee Howard -
state mechanisms for variosu technologies in which order they should be usd
do we need to support multihoming?
Requirements for the smart grid.
Alain durand -
pcp?

Lee howard -
didn't want to include things that are incomplete

wess g (jabber)-
pcp?

Joel j (jabber) -
port control protocol

stuart cheshire -
concerned that this leaves us with one layer deep routing

randy b -
not cheered by the topology contraint
also 1812 in the router

fred b -
ipv4 should be a off the table
I don't have a problem with ospf

randy b -
is worried about rip

tony (jabber) -
+1 to that comment

tom herbst -
one case is ula scopped addresses

lee h -
we want requirements as approiate

lorenzo c -
I kind of despise ula in general but if we solve the topology problem
with ospf then there's a boundry
once we've figured out how to given /64s  to everyone the ula works.

Lee h -
take it to the list

ole t -
this document is suppposed to be non-inovative lorenzo please write the
draft.

Fred B -
We're finished

done