[v6ops] IETF 79 Meeting minutes - Draft

[Joel Jaeggli <[e-mail]>]

IPv6 Operations WG Meeting minutes - IETF 79

Please register opines on Drafts presented during the meetings using the
Survey Monkey:

Wednesday's Agenda: http://www.surveymonkey.com/s/KJY9WNS
Friday's Agenda:    http://www.surveymonkey.com/s/2PRZB9B

Survey closes Friday the 19th of Novmeber and the results will be sent
to the list.

Note takers Ed Jankiewicz (scribbing) Joel Jaeggli (jabber)

--------------------
Wednesday Nov 10 9:00-11:30
--------------------

Agenda bashing
 Straw Poll regarding Wednesday
drafts:
http://www.surveymonkey.com/s/KJY9WNS
Note Well
Agenda bash
Packed schedule, please move along

1 Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts
2 Opening TCP Sessions in Complex Environments
3 IPv6 Multihoming without Network Address Translation
4 Advanced Requirements for IPv6 Customer Edge Routers
5 CPE Considerations in IPv6 Deployments
6 Network signaling for IPv4/IPv6 protocol selection for end-systems
7 Non-Managed IPv6 Tunnels considered Harmful
8 6to4 Provider Managed Tunnels
9 IPv6 AAAA DNS Whitelisting Implications
10 DHCPv6 Prefix Delegation as IPv6 Migration Tool in Mobile Networks
11 IPv6 in 3GPP Evolved Packet System

* Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts
  25-Oct-10, <draft-wing-v6ops-happy-eyeballs-ipv6-01.txt>

Goal is to keep users happy with IPv6 so they do not abandon.
First hits on IPv6 search is how to turn it off.
Easy to break things, tunnels, peering, IPv4 responsiveness better, islands
Proposal: probe, learn, quick fallback
Current behavior leads to 20 sec delays when things break.
Probing:  dual thread, simultaneous attempts
Learn: which works first will be preferred in the future
Fallback: quickly and reset on new attachment
Experimental in links browser
Delays multiply with rich content from multiple sources

Remi Despres – fully support
Ted Lemon – extra complexity to eliminate extra SYNs, premature
Sheng Jiang  – don’t like title – go to apps area, Dan – moving from v4
to v6 without harming user, SCTP and TCP separated
Brian Carpenter – referrals in Apps area, they would love us to solve
it.  Dan
Mohsen -  internet=web for users; this improves user experience.  Keep going
Colin Perkins – support, avoid too many connections at once, pacing
important
Fred Baker – TSV area randy stewart – SCTP implementation, zero delay
for multiple attempts
H? – multiple probes through stateful devices? Studies?  Dan – not yet.
 TCP does this all the time.  Problem may be overblown by transport
people, reality is
H? – change over has a delay too?  Dan – encourage it
to be shorter and tighter, not full TCP timeout.  Encourage apps to run
a timer and tighten.
H? – oscillation?  Dan – further study.

Fred – rather than polling on each draft, see surveymonkey polls and
give your opinion and guidance.  Any emerging consensus will be
discussed on list.

* Opening TCP Sessions in Complex Environments
  18-Oct-10, <draft-baker-v6ops-session-start-time-01.txt>

Last night in TSV area
RFC 5461 – response to soft errors; maybe they will go away, but ingress
filtering, probably not
How would you test the start time in Happy Eyeballs?  Draft test plan
V6ops – better ideas in TSV?  Otherwise let’s adopt Dan’s draft

* IPv6 Multihoming without Network Address Translation
  26-Jul-10, <draft-troan-multihoming-without-nat66-01.txt>

Presented before, reporting activity in other WGs
Also applies to v4/v6 multihoming
6man adopted 3484 update and DHCP option, addr-select
MIF working group route info distrib and server selection drafts; added
to MIF charter
Pre-populate host, or feedback from the network.
Questions? Comments?

Joel Jaeggli – any specific drafts we should review?
Address selection Fujisaki – main challenge

* Advanced Requirements for IPv6 Customer Edge Routers
  25-Oct-10, <draft-wbeebee-v6ops-ipv6-cpe-router-bis-04.txt>
  Ole Troan

– follow on work
CPE requirements for smart power, following this
Draft changes, added 6rd and dslite.
Device profile, non-innovative referencing existing work.
What is the home topology to generalize the simple CPE work?
Chained IPv6 CEs, in v4 it is a multi-level NAT, in basic IPv6 it
doesn’t work unless you do NAT66
Strong use case for this topology.  Either say don’t do it or try to solve
Use case 2 – add a sensor network in the home, separate connection to
power grid
Use case 3 – loop topology, multiple ISPs – self configuring?
“routed” home problems
Solve problems, optimize, one use case over the others?
Self-configuring
Firewall by default, but need to discover role (BR vs internal router)
How to configure ULAs
Several problems do not have currently documented solutions, so nothing
to reference, does this limit the scope

* CPE Considerations in IPv6 Deployments
  18-Oct-10, <draft-herbst-v6ops-cpeenhancements-00.txt>
  Tom Herbst

802.15.4 zigbee
Moving to IPv6
California – multiple million+ network deployments
Also Australia
IP on 802.15.4 – small MTU, fragmentation, mesh
Routing everywhere, breaks subnet model
Neighbor discovery is very different
Requires L3 forwarding – have to be a router
Consumer access to Utility Co data
Results in multiple routers, from ISP and Utility
ULA in the home area network; intrahome focus.  Connectivity within the
HAN without ISP
Link-local is useless, can’t route through mesh – must use ULA
The two routers create their own ULA sets, how to deal with?
Need a routing protocol on by default
Firewall config – many security issues, not sure of solution yet
Multicast DNS for discovery; only defined for link-local.  Need a larger
scope, site-local multicast and ULA scoped responses
Like to see this get integrated into other work in progress

Ole – what does the room think
? did you consider rfc 5006 instead of mDNS?  Tom – not a consensus
Jari Arkko – connectivity – only access to power sensors within the
home, not remotely?  Tom – initially.  If it is to be globally
available, should be configured with global addresses.  Jari – more
considerations later.
Dave Thaler  – preference for limited scope, close to single router
network.  Homes work best with a single subnet today.  Lots of consumer
stuff assumes single subnet.  What about ND proxy?  Get the existing
protocols to work.   I want the topology to work, avoiding multiple
routers, i.e. reduce complexity.
Tom – the ND is very different in mesh network.  Not really the same
thing.  How to proxy between them?
Dave – still what I would prefer
Mark Townsley – option three.  Solve “routed home” rather than hacking
to maintain a faked out single subnet model.  Reality is multi-segment
home, different media, home/guest network with routing between.  Home
network needs to evolve.  Can’t work just sometimes – it has to work no
matter how connected.  Focused serious effort.
Lee Howard – current CPE router draft is getting there, for this scope
we need to solve the whole problem – this is getting more complex, and
we need a problem statement to define the set to solve
Tony Hain – disagree with Dave – need to go to 3.  Ad hoc collection of
today kind of works, vendor assumptions, we need an architecture, set of
tools; avoid vendor conflicts
Eric Kline on Jabber – what is the admin boundary?  How does it know?
Mark T – requires protocol mod; that is the problem
Remi – support.  Need a solution for item 3.  I have a proposal.  Third
option applies to the simpler case.  Maybe we provide a short term
solution for the simpler case
Kurtis Lindqvist – 1 and 3 are not in opposition, could do both, despite
text in the draft
Ole – two tracks can be done together
Fred Templin – provider independent prefix.  Stable, multihoming.  IF we
could get this
Don Sturek - support for item 3.  Liaison with Wifi this should be happening
Ole – maybe a bar BoF, to explore solution space
Mark – need a real protocol design effort beyond 3.
Fred Baker – first need requirements to determine what to solve.
Mark – number three actually just defines not solves the problem
Dave T – homegate discussion led to “homenet” including both v4/v6
Jari – not just a requirements doc, need a solution.  Requirements doc,
how-to using existing tools, not clear we need a new protocol.  Other
places to do the work.  Intarea, we should not create an effort here to
redo DNS, routing, etc.  they should look at.  What can we do with
current stuff?  Most of what we need.
Fred Baker – we are chartered to do requirements, but should
Don S – should not solve the problem in v4.  Too many devices
Tony Hain – scope charter, historically v6 in existing networks.  This
is looking at structures in new topologies.  Requirements in scope,
solutions out.  Treading on defining an architecture
Fred – wait for homenet?  Or prep in case it ever gets started
Ole – we could do something on 1 to finish it off, in parallel on 3.
Meet sometime to start work.
Fred – general feeling (hum) this is the way to go

* Network signaling for IPv4/IPv6 protocol selection for end-systems
  16-Aug-10, <draft-vandevelde-v6ops-pref-ps-00.txt>

Gunter  Van de Velde
Awareness of a particular need to have from a network operator
perspective.  Problem statement
4 vs 6 preference, such a tool would help
A way for the network manager to prepare the network for full IPv6,
disrupt the chicken/egg problem
May not want to immediately start using IPv6 just because there is a AAAA
End-system configuration
RFC 3484 impact, application impact.
How to signal preference or preconfig, network dictate, etc.
Overlap with fujisaki, addr-select-considerations
Do we want to do this?
Brian Carpenter – not just a problem statement, starts into requirements
as well.  Not a bad thing.  A host should be able to ignore this, to
permit experimenting with IPv6.   Real issue, good idea to address
Dave T – yes, good idea.  Overlap with 6man doc, does it make more sense
to keep a separate doc?
Gunther – different angle.  Eliminate overlap and refer to the other doc.
Dave – things that 3484 didn’t solve, and why you want to do something else.
Colin Perkins – yes, good idea.  A lot of equipment that will ignore
this, how long to upgrade and deploy to make this useful.   Real problem
– needs significant penetration to be useful
Fred Baker – how does this relate to Happy Eyeballs?  Would that
approach work?
Gunter – Happy Eyeballs is one possible solution
Dave T – this defines some problems that Happy Eyeballs doesn’t solve.
Stig Venaas – there are cases where a manager might want to disable IPv6
entirely, could negatively impact user experience
Joel J – in managed environments, these things happen today.  Solutions
exist, although not captured in protocol/draft form
Fred Baker – should adopt as a WG doc – answer in surveymonkey poll.


* Non-Managed IPv6 Tunnels considered Harmful
  31-Aug-10, <draft-vandevelde-v6ops-harmful-tunnels-01.txt>

Controverse-o-meter
What is a managed tunnel?  Definition in draft
End user has a contact to complain when connectivity not working.
Security, performance and integrity are managed
User experience should be like real native connectivity.
Differential viewpoints of end user, enterprise and service provider.
Noble goal of IPv6 Internet – as good or better than IPv4.
Do non-managed tunnels do this?  If not, why do they exist
Early adopters, decouple readiness between infrastructure and application
Not scalable
Early adopters are happy with non-managed tunnels, but will not work for
the mainstream
Hard to provide managed service on an unmanaged infrastructure
Content providers can’t offer universal IPv6.  Complex white-listing to
get around
Wes George – should cover more recent events, multiple ISPs acknowledge
6to4 now.  Better off the solution is to make the reality less harmful.
 If you are an ISP, drop in a couple boxes to make it work better,
manage locally (at least in one direction) the content provider can do
it in their networks (for the opposite direction).  Saying “don’t use”
makes it second class.
Brian Carpenter – 6to4 plus anycast heresy is here to stay.  More
important to explain to ISP with Content Provider how to advertise good
routes for 2002/16.  Similarly for teredo.
Yiu Lee – no control as operator, already in OS and home gateway.  No
way to avoid.  Need a recommendation
John Brzozowski – not expensive, not difficult to deploy 6to4 relays.
Even with IPv6 content, the 6to4 path is not preferred.  It would be
dramatic to alter this behavior.  6to4 helps when IPv6 is triggered.
Even the return path is not so bad.  Broken home networks are
problematic.  The traffic is out there, even if you don’t do anything.
Dave T – improved a lot over the last time.  Controverse-o-meter is
accurate, reduced the controversy.  The observations are valuable, still
controversy about what to do.  Analysis is valuable, more discussion
about what to do about it.  Positioned to content providers, but
non-managed tunnels can be used where no IPv4 is available.  Need to
keep that in mind
Remi – problems are explained.  6to4 uses a global address, and is
reachable.  Don’t break this with translation.  E2e transparency should
be preserved by all means.  Consider in solutions
Mark T – less painful with happy eyeballs.  If this is a WG item, we can
work on it
Fred T – opinion – considered harmful has negative connotations.
Overworked and jaundiced term.  Fragmentation is still with us.

6to4 Provider Managed Tunnels
22-Sep-10, <draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-00.txt>
Red box on every slide probably
Some controlled CPE to include dual stack, ds-lite, 6rd.  and
uncontrolled CPE
6to4-PMT for the unmanaged IPv4-only endpoints.
Can we use NAT66 prefix translation, just one tool.
Pulling v4 routing into v6 not a popular option
6to4 relay is easy to turn on.
Challenges, harms e2e transparency, common NAT problems.
CGN non-rfc1918 can break 6to4.
Real problem, last resort IPv6 connection.  Not an option to ignore
these customers.
Wes George – corner case, CGN with routable space, breaks 6to4.  One
application where this makes sense to intercept the brokenness.  I don’t
support this as a general solution, but to target at that issue it is a
good thing.  Useful in that perspective
Brian Carpenter – don’t like this, ditto Wes.  Get the operators to
deploy 6to4 relays.  Keep content providers happy.  But focus this only
on the corner case this is the only solution
Remi – does not meet the criteria of maintaining the current operation
of 6to4.  NATs and cascade of NATs kills IPv6.  Solution includes
stateless NAT66, still under study.  Restrictions on subnets.
Consequences of checksum neutral approach still under study.
Ole Troan – apologies, I work for a vendor with 6to4 on by default,
cannot be turned off.  Can we characterize this as a way to make 6to4
work better.  Return path.
Victor K– use case for CGN environment.  Last resort v6
Fred T – prefix translation – is it advertised by broker?
Victor – real provider prefix.  Provider aggregate
Joel – Eric Kline – OSes depref 6to4.  Is this last resort for IPv6 only?
Victor – yes.  Not a lot of work.  Less support cost
Mark Townsley – if you ask us to do this and give us enough money, we
will do this.  Don’t ask.  This would be a distraction from more
important problems.  More 6to4 relays would be better than this.  Hosts
may be abandoning 6to4, so should be declining.
Victor – v6 only endpoints may increase it
Mohsen – don’t like, wrong signal to providers.  Unserious approach to
IPv6.  You should tell operators they will face some pain
Victor – hard to get v6 capable CPE, not an option to break things.
Operators have real issues here
Tim Shepard – slowly realizing how incredibly harmful this is.  I have
6to4 addresses at home, in DNS.  Customer opt out is good, but the ISP
doing this would break my setup.
Victor – easier to work with the clueful IPv6 users, rather than the
majority with no idea on IPv6.  If you go behind CGN you’d stop work anyway
Lee Howard – this signals ISPs poorly.  ISPs are already deploying IPv6.
Fred – Dlink
Joel – netgear.  Look for the v6 ready logo.  Way better than 2005.
Victor – success rate of off-the-shelf IPv6 is low
Tony Hain – this buys into a problem space that is not helpful.  Creates
a new set of problems due to NAT66, avoiding the most helpful thing,
putting content on 6to4 as well.  Hack that doesn’t quite really work.
Wrong step
Victor – experiments with real customers and endpoints, we will come
back with those results.  Report back in Prague.

* IPv6 AAAA DNS Whitelisting Implications
  22-Oct-10, <draft-livingood-dns-whitelisting-implications-01.txt>

Jason Livingood
How dns whitelisting works, and why sites are considering.
Implications, solutions, alternatives
Access control list on the authoritative DNS server, determines whether
you get AAAA back
Doc lists a lot of downsides/risks.  Primarily management burdens.
Opaque and administratively challenging
Advise users and help them solve
Appropriate venue to house this document, and looking for feedback and
comments
Detailed reviewers needed
Mohsen  happy with this, clear explaination of implications.  Continue
here and/or DNSOPS.  One possible conclusion is “don’t do it” it
balkanizes the internet
Wes George – advise users of IPv6 impairments, see another draft on how
users report problems.  More on the ISP side.  Results in confusing
messages, don’t blame us it’s the ISP problem.  IPv6 test sites that
might be helpful.
Jason – 2011 awareness events
Ron Bonica (via Jabber) – should be in v6ops
Danny McPherson – belongs here, share with dnsops.  Fragmenting the
namespace, problematic.  Important issue to highlight.
Mark Townsley – Happy Eyeballs would help here.  “google please do IPv6”
Eric Kline, did it, whitelisting allowed them to do it.  Good thing
(now) but should go away.
Kurtis – draft should ref happy eyeballs, de-pref on 6to4.  Over time
this will become better
Joel – balkanization harmful, but something you just might do.
Fred – surveymonkey WG item means the work should stay here

* DHCPv6 Prefix Delegation as IPv6 Migration Tool in Mobile Networks
  12-Oct-10, <draft-sarikaya-v6ops-prefix-delegation-02.txt>

Not obvious how to do in a Mobile Network.  Intended BCP for such
applications
SLAAC with a relay
Prefix delegation per RFC3633
Stateful – MN starts, AR sends IA_PD
Comments on the list, issues resolved, stable.
Journi K.  – SDO 3GPP; does the RA contain multiple prefixes?
Bechet – one prefix is ok, but more than one should be supplied
Journi – tied to one /64.  Next slide, does the MN configure its own
address based on the delegation?  In 3GPP this is not the approach.  Fix
the text.
(take to the list)
F?  agree with Journi concerns.  Overall specification of PD in 3GPP is
still developing.  Postpone until that resolved
Jonne -   trying to document what is done or trying to make
recommendations.
Bechet – useful to make recommendations on how to use PD, regardless of
customer
Jonne- either late or early, depends on use of the document.

* IPv6 in 3GPP Evolved Packet System
  21-Oct-10, <draft-korhonen-v6ops-3gpp-eps-04.txt>

Developments since Anaheim.
Access Point Name
Bearer types include v4 only, v6 only and v4v6 (new in r8)
Dual stack in a mobile device, before r8 needed two bearers, now a dual
stack bearer
R10 will include prefix delegation based on 3633
Fred – what should this WG do?
Journi – AD track individual submission
Fred – Jari is carrying it
Jonne – burden on AD
Fred – the WG can take on

Please update SurveyMonkey.  Continue Friday.

meeting closed 11:35

------------------
Friday Nov 12 13:00-15:30
------------------

12 Welcome and Introduction from the China Network Operators Group Dong
Yan, CNNOG and CNISP
13 Framework for IP Version Transition Scenarios
12.5 Call the question: Shared IPv4 Prefix for Carrier Grade NAT deployments
14 IPv6 Transition Cable Access Network Use Cases
15 IPv6 Transition Use Case For a Large Mobile Network
16 IPv6 Transition Guide For A Large Mobile Operator
17 Use Case For IPv6 Transition For a Large-Scale Broadband network
18 IPv6 Transition Guide For A Large-scale Broadband Network
19 Naming IPv6 address parts
20 An Annotated Bibliography for IPv4-IPv6 Transition and Coexistence
21 NAT64-CPE Mode Operation for Opening Residential Service
22 Considerations for Stateless Translation (IVI/dIVI) in Large SP Network

* Welcome and Introduction from the China Network Operators Group
  Dong
Yan, CNNOG and CNISP

Representative of CNISP and CNNOG
Welcome and introduce the orgs
China
Internet Service Provider Union, national industry alliance
6-link IPv6
implementation program, conferences, promotion, magazine
IPv6 training
with APNIC
CNNOG China Nework Operators’ group
annual meetings starting
2005
more technical than CNISP
6-link earlier this year, promotion and
implementation
growing from one demo node to phase 2 – 6 nodes in major
cities, 10 ISPs 20 Content
Baidu and others

* Framework for IP Version Transition Scenarios
  18-Aug-10,
<draft-carpenter-v4v6tran-framework-00.txt>

Brian Carpenter
time to look at transition scenarios again, series of BCP or info
docs
not protocol specifications but technical and general advice
not
promotional or IPv6 for dummies, for ISPs ready to move on
IPv6
definition of what these docs should contain, topics including
transition and coexistence, legacy operations
not a deployment plan
but
Is this useful
Jonne – went through this several years ago, not very
pleasant.  Hard to be detailed and still please everyone.  All the work
that has come after is despite that effort.  This is advice for
operators, but with our knowledge and granularity, leads to argument,
lots of pages with limited utility.
Brian – lot of ISPs that don’t
attend IETF and NOG, but they read RFCs.  We have knowledge that they
will soon need
Jonne – not necessarily the right place.
Mohsen Souissi –
useful especially now.  IETF is the reference and they look to IETF to
do this job or they will be lost.  Not intended to be standardized but a
way to move forward.
Kurtis – talking past each other.  Operators are
pushing for various things, at opposition
Basaraj Patel – not all
operators, but many are here. And do understand the IETF, options and
specification.  Toolbox is defined, they can pick and choose.
Marla – a
little disgusted at the personal attacks.  Service providers are at
least doing it, it’s not going to be perfect.  Trying to get everyone on
the net.  I support this, where do people go to get documentation,
instead of creating new orgs do it here
Jonne – how to use and tradeoffs
would be good.  Long docs without knowledge of access systems, and
redundant.  Document the current transition mechanisms and how to make
the tradeoffs
Randy Bush – if the docs describing the mechanism is
insufficient, fix the doc.  This group should not waste time discussing
this is not 
Victor K – support this doc, a book would not vet through
this group, operators are here and willing to put this work together.
Mutual interest in getting everyone to IPv6.  Complex multidimensional
problem.
Fred – comment on survey-monkey

* IPv6 Transition Cable Access Network Use Cases
  11-Oct-10,
<draft-lee-v6ops-tran-cable-usecase-00.txt>

Victor Kuarsingh
Several use cases applying to cable access
Jumpstart IPv6 with IPv4 only
use case – 6rd 
combinations of access network, hosts, pub/priv IPv4
address space leading to different choices of technology.
Is this
useful?
Ed Jankiewicz – support this, it will provide a good example of
the analysis and comparative evaluation of the Transition Mechanisms.
And should be useful to other similar operators.  Cannot provide
comprehensive instructions to all, but some helpful advice on how to
apply the tools.  I appreciate what Randy said – but these use
case/transition guides and Brian’s draft could be very good information
about how to fix the fundamental specs

* IPv6 Transition Use Case For a
Large Mobile Network
  18-Oct-10,
<draft-zhou-v6ops-mobile-use-case-00.txt>
* IPv6 Transition Guide For A
Large Mobile Operator
  18-Oct-10,
<draft-tsou-v6ops-mobile-transition-guide-00.txt>

Tom Taylor
RFC 4215 started this use case analysis; several other drafts advance
the analysis
LTE architecture
“IMS” multimedia service, applies to other
distributed applications as well
for each use case, look at the prior
and more recent work, and derive a proposal
IMS – media path is separate
from the signaling (missing on slide)
RFC 4215 looked at several IMS
scenarios, and it will be difficult to bring applications up to
date.
Use of private addresses, NAT will get expensive with
scale.
rewrite the doc to reflect the slide
Jari – comments to be on the
list; any work here should also include the signaling plane, user
traffic, IMS different drivers and difficulties.  6rd without IPv6
access network, easy to use without extra tunnels.  
Jari – how does
this relate to work going on in 3GPP?  Not to repeat the effort, but
value-add
Frank – closer linkage to 3GPP docs would help.  ICE is
controversial, ref to 3GPP needed.  On technical, stateless NAT64
doesn’t work in mobile networks due to SLAAC.  NAT behavioral issues.
Not the same issues in DSlite with DNS.   Cleanup, would love one doc on
this
Stephano – three related drafts on v6 in mobile, makes sense to
combine.  Two Tsou docs and v6 mobile.
Jonne – good example of the
problem I brought up.  Some of this is already done elsewhere, and 3GPP
is already working on this.   Joint meeting and progressing, no need to
repeat here.  If we don’t understand everything, guidance can be
harmful.  Leave it to the guys who know how to do this.
Jari – AD hat –
cooperation with 3GPP on this, needs to interface with that effort, not
stepping on the toes.  Expertise should be put to the right effort.
Fred
– please converse among the authors of the 3 drafts mentioned

* Use Case For IPv6 Transition For a Large-Scale Broadband network 

20-Oct-10, <draft-huang-v6ops-v4v6tran-bb-usecase-01.txt>
* IPv6
Transition Guide For A Large-scale Broadband Network
  19-Oct-10,
<draft-yang-v6ops-v4v6tran-bb-transition-guide-01.txt>

Large scale broadband network.  
> 60M subscribers, fast growth,
unmanaged CPE
IP and MPLS backbones
scenarios with new or legacy
BRAS
Solutions evolve over time – dual stack backbone, to 6PE to
v6-only
regional area broadband, DSlite, NAT64
does not yet consider
issues of L2 access network
comments and contributions welcome!
Brian –
looking at these two and the previous two docs, what do we gain from
separating the scenarios from the transition guide?  May be more user
friendly to combine.
adding experiences 
Joel J – if ISP is growing so
quickly the legacy is shrinking, maybe transition technologies are less
important.  Applicability, there are maybe 100 ISPs that meet the
criteria, and these have much of their own capabilities
In developing
countries, the knowledge and experience base is less. 

* An Annotated
Bibliography for IPv4-IPv6 Transition and Coexistence
  25-Oct-10,
<draft-jankiewicz-v6ops-v4v6biblio-03.txt>

Ed Jankiewicz
While Fear, Uncertainty and Doubt about IPv6 are still prevalent, it
appears Ignorance, Denial and Blame are gaining on them.  No reason to
panic, but time to get working on IPv6.  As long as we have IPv6 widely
deployed before IPv4 addresses start to run out everything will be just
fine…Oh.  There seems to be a daily weather report about when IPv4 will
run out.
Maybe it is time to panic.  See
http://www.youtube.com/watch?v=eYffYT2y-Iw from Cisco
Growth will be impeded by the need for coping mechanisms, some of which
are not universally beloved.  Lots of work in several working groups,
we’ve gone from virtually no solutions to too many.
At IETF 71 in Dublin, Oct 2008 in Montreal, lots of drafts emerge, so I
pulled together a list to prepare.  It seemed to be helpful at the time,
then dropped. At IETF 78 there was another explosion of interest in
transition, driven by some folks in the ops community, seemed that the
bibliography might be necessary at this time.  There are lots of ideas
circulating, some overlapping and even redundant, and work going on in
several groups so it is easy to lose track of what has already been
discussed.
See the draft for the “3 laws of coexistence mechanism” a way to
evaluate and contrast the mechanisms.  What is harm?  Anything someone
might write a “considered harmful” draft about.  Do what you need to do
within your network, but don’t negatively impact others’ net experience.
 Have an exit strategy – keep moving towards, promoting, enabling IPv6.
 Especially do not impede early adopters.  And don’t reinvent the wheel.
So what to do with this draft?
Lee Howard – appreciate the draft.  I’ve said “how can IETF help?  Help
less.” This draft indicates the problem we have – too many ideas, too
much help.
Ed – it is a symptom.
Brian – please include a disclaimer
that appearance in this draft does not constitute any official
endorsement of the approach
Ed – as editor, I will make it clear that it
is just my opinion, nothing official
Joel – this is more than just a
bibliography, it is a curatorial effort, your editorial voice comes
through, humorous at times.
Several suggestions that it might be better to set this out as a web
page or wiki.  Discussion on the mailing list as to where the right home
would be.

* NAT64-CPE Mode Operation for Opening Residential Service 
  18-Oct-10,
<draft-chen-v6ops-nat64-cpe-00.txt>

Destination server on private IPv4 network, with NAT64
Jari – interesting use case, not sure what is changed in the
application.  Any protocol, behavior changes?
Only operational. 
Jari – within the scope of Behave docs, maybe a good
applicability statement on it

* Considerations for Stateless Translation (IVI/dIVI) in Large SP
Network 
  25-Oct-10, <draft-sunq-v6ops-ivi-sp-01.txt>

Sun Qiang China Telecom

Focus on how to deployment of translation in large ISP network.
dIVI –
extension sharing public IPv4 addresses.
no need for ALG or DNS64
Lab implementation, dual stack host, global IPv6 address space and IVI
address space
Manual config in the lab
Looking at real SP network deployment.
Fred – what comments are you looking for?
Randy – management of and by IPv6.  This is the important point.  What I
want is feature parity, the rest is all noise and days worth of
presentations
Lee Howard – please state your correct name
Fred – China
Telecom – aggressively deploying IPv6, but keeping their business
operational
Kurtis – most applications work?  Specifics or classes of
apps, per Jari talk
Fred – in China some specific enterprise
applications (banks eg.) busily working with them to fix and
accommodate
Tony Hain – is this really an informational document about
an experiment, or is it saying the WG should do something else?
Sun – both experimental results, and deployment considerations.
Information for other ISPs
Tony – maybe looking for the WG to validate the recommendations

* Draft-weil-shared-transition-space-request-01
  Chris Liljenstolpe

suggested in opsarea to bring this to v6ops, primarily a vehicle to
support v4-only end devices on run out until v4 over v6 infrastructure
in places
We don’t like blowing stuff up on purpose
NAT444 least disruptive, not ideal.  Period of time
Need a re-useable address block that will not conflict with 1918 space.
/10 or adding up to /10 to be requested from IANA
Not global private, don’t use in device configuration, most users will
not see this
Pragmatic, not pretty
Tim Shepard – looking at old draft
Suresh – all CPE use 192.168, some use 10.0.0/24
Telstra – plurality use standard addresses, small numbers use other ranges
CanCan – why do you need to register a range?  Why not cut off from your
own allocation, CPE using net 10 is limited to US and Canada – China
does not have the net 10 problem
Chris – need some number of addresses to address CPE, need more
addresses.  We can make one request and reuse it, or make lots of
individual requests
CanCan – this is unfair, to take this space to solve your own
problem
Chris – doing this separately will more quickly exhaust the pool
Tim Shepard - /10 instead of /8 10.192/10
Chris – interesting to know how much of a problem that would be, test
would be interesting
Wes George – contradict your own justification, any use outside of this
would be “off-the-reservation” there is a small number of SOHO router
manufacturers, why not tell them they are currently off the res?
Chris – they are not – you would be asking people to renumber
Wes – need some real data to back up the assertion.  It’s a big enough
deal that we need clear data, proof  why.  Don’t understand the threat
to ask for more space, you already have enough space for current
customers, if you request IP space right now, if you could justify it
why don’t you
Dan Romanescu -  IESG has a draft on the table, pending a couple
discusses, that says don’t do this, straw poll in IESG.  Soon to be an
RFC.  The IESG would object to this.
Frank – different behavior with public/private address space
Chris –
Jari – how fast is not relevant.  What does matter, impact afterwards.
One area of concern is software with built in knowledge of 1918 space
Chris – only between the CPE and CGN; other software shouldn’t see this
Jari – potential for leakage.  That area is more of a concern
Fred – any specific products?  Cisco has products with martian filtering
Suzanne Wolfe – hope the IESG members are in these discussions now.
This is a bad idea, but like so many ideas in the transition space, may
have to live with this
Mohsen – more than ten years we’ve been telling you to act on this; how
do we know you will really go to IPv6 if you get this
Chris – waiting for kit from vendors, we are moving ahead
Lee Howard, operator.  Well documented in donley nat444, why we really
don’t want to do NAT444.  Consumer electronics do not support IPv6, no
way to get them out there.  Getting from one home to another when IPv4,
will not work.  This is needed
Marla – author of the draft in IESG.  Not
really a recommendation, just documents the consequences.  As to going
to IANA, the whole world changed when transfer proposals were advanced.
 Transfer proposals exist, allowing commoditization of address space.
RIR allocation was not justified before, and have not done that because
of trying to be ethical.  Instead of having all these folks go for their
own /8, get one /10 that they can share.  We are trying to get this
moving, the writing on the wall has been there, but it is not easy.  It
is a human environment not purely technical.  This is more kind to the
whole community.
? echo, there are operators thinking about this that are not here today.
 We are where we are, it is a fair request, consider it on its merits
and practicality.
Dave Thaler – in a provider network, might have CPE management, others
don’t.  If the CPE has 6to4, the connectivity would break.  Net PMP.
Application SDK have macros with the private address space, so there is
a danger of something bad happening.
Chris – these are NAT444 issues to.
Joel – these new addresses are not private use scope, so some apps might
make the wrong assumption about these apps.
Chris – NAT444 breaks all these things regardless of the address space.
Joel – but they will assume they can us NAT64
Dave – danger that IPv6 experience will get worse.  Running out of IPv4
should improve the IPv6 experience (hasten the day).  With your own
space it would be globally routable.  The next group, VPN vendors have
the same problem
Chris – we know this will break things.
Joel – breaks different things
Wes – homegateway with 6o4 will see this
Chris Donley – three things, shared /10, individual assignments >/10,
squat on others all break
Joel – individual assignments would work
Wes – if you could meet the RIR requirements to justify more space you
would have.  Squatting won’t work due to transfer.  Also holders will
not yield space.
Randy Bush – IIJ.  Point that Dave made is germaine.  As soon as this
gets set aside, VPN users will grab it too.  Zero sympathy from me.  It
was possible to deploy, laziness and greed.  You are here because APNIC
told you to stuff it.
Tim Shepard – NAT444 is going to happen.  As much as I dislike it.  Sad.
 Can’t change history.  Choice is NAT444 with in the middle with the
address being the /10 shared space vs 10.192 space in the middle.  My
gut is that 10.192/10 in the middle would do less harm in the long run.
 Both of these are better than depleting the IPv4 faster.  If you can
use 10.192/10 instead, it will be less harmful.  1918 is compiled in;
globally routable used as a 1918 is potentially very harmful.  We really
need to know this
? speaking as a private network citizen.  Don’t want to go into how
ugly, unfair, etc.  but take another look at how address space is
administered, 2500 or 200 or 50 Service Providers, can any SP justify
this use to the RIR.  If just one SP got this block of space, and
decided to share it, this could be done
Chris – then one RIR provides the space for everyone to use, may be an
problem
Jari – interesting politically, but not so significant.  Per Tim’s
proposal, subscriber should default to this set of net 10 addresses.
How many break against that.  Could compare with how things break with
new space.  If we had that it would be simple to decide.  Can’t wait a year.
Fred – netizen, map showing distribution of IP address space, looks like
the night light map.  The addresses are concentrated.  The rest of the
world uses NAT444.  How?
Joel – what is the frequency of 1918 usage?  You can find this out from
large providers SIP registration, and could be mined.
Fred – can we call the question?  Clear consensus, actually two, in
opposition.   Not an IETF consensus
Chris – in ops, about 2 to 1 for, with strong objections.
Jari – for myself, with the data discussed, use all means possible to
answer the question of which would be less harmful.  Without that data,
big battle.
Lee Howard – one of every gateway and see if it breaks
Randy - Lars’ gateway work
Chris – what is the distribution of 1918 space
Randy – some bellovin work a couple years back
Kurtis – India has less address space than being discussed, yet they are
able to multiple NAT it
Chris – bellovin data, SIP registrations
Lee Howard, start with major CPE gateway vendors.
Chris – some data within a month, but how/where to discuss
Lee – once a major case that shows it breaks, that would probably end
the research
Randy – confused on IETF process, seems to be no consensus to do this
here, how much more time
Wes – please go through the entire space.  Willing to accept smaller
blocks that add up, if there are gaps, this is a long tail problem or
not.  Maybe some at the edge would break
Chris – technically non-contiguous is ok, but a support nightmare.
Fred – primary objective is to produce consensus where none exists.
Getting objective data upon which a rational argument can be made
Consensus call:  if the data shows that this is the only option, would
the group support having the operators do this
Wes – there are other considerations besides the 1918 breakage, maybe we
can extricate that out.  We will look at a follow-up draft
Tim Shepard – can you use 10.192 or some other block within RFC 1918.
You as a provider may feel less pain with a block outside 1918, but will
cause pain for others

Chairs
Request for hum showing support for (first) or against (second) this
proposal were to to arrive as a draft?
Not strong support for either position. given discussion so far would
conclude that there is definitely no consensus.
topic closed

meeting adjourned 15:51:20 nov 12