[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
memo, 1st day PM
- To: v6ops@ops.ietf.org
- Subject: memo, 1st day PM
- From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
- Date: Thu, 19 Sep 2002 09:14:25 +0900
- Delivery-date: Wed, 18 Sep 2002 17:14:53 -0700
- Envelope-to: v6ops-data@psg.com
[not a official minutes]
shin miyakawa (operator's input)
commercial IPv4/v6 dual stack ADSL operation
tokyo only, $6/mo, 8-10Mbps DSL
existing application - IPv4
new applications (VoIP, VCR, whatever) - IPv6
specification between NTT and router vendors
translate spec into informational RFC?
RADIUS -1- BAS -2- DSL router -3- host
1: RADIUS/IPv6
2: PPP(IPv6CP), DHCPv6 <-- this part, NTT cares
3: stateless addr conf, DNS discovery (up to customer)
1 IPv4 dynamic, /48 IPv6 static
IPv4 addr change - reassignment at POP, whatever
IPv6 friendly DNS server
customer: primary server (IPv6 only)
NTT: secondary server (IPv4/IPv6)
hesham: where to buy router?
shin: yes, there are vendors (JP and non-JP).
thaler: ::53, subnet number = 0x0000?
shin: yes.
?: charging model? per-address?
shin: no, not for IPv6.
shin: pressure for preserving IPv4 addr is severe in JP
translate it, and make v6ops wg document (informational)
hinden: not the only way to realize DSL service (clarify)
shin: correct, example scenario
itojun: change control?
shin: ok
important thing: use same mechanism everywhere
include it into ISP document
?: what kind of other magic numbers are you using?
shin: ::1, ::2
?: there are other translators involved in SMTP and such?
shin: no, customers use IPv4 (dynamic) addr
intro to breakout session
cellular
scenarios document changes
introduction to relevant 3GPP concepts added
PDP type PPP added
picture added
this document should be pretty stable by now
GPRS scenarios
dual stack -> IPv4/v6 nodes
IPv6 only --IPv4 cloud-- IPv6 only
IPv4 only --IPv6 cloud-- IPv4 only
IPv6 only -> IPv4 only
IPv4 only -> IPv6 only
IMS scenarios
target dates
04/2002 - first rev
09/2002 - second rev
design team started
05/2002
first solution draft published
IETF54
09/2002 second draft
solution draft finalized
IETF55/end of 2002
could this document be taken as a WG item?
agenda for drafting session
solution, document introduction
nat-pt issues
scenario walk-through
GPRS scenarios
transition scenarios with IMS
wrap-up
randy: confused about 2 documents
environment, what we need, how do we solve problems
bound: do we want to do the same for 3GPP-2?
soi: not sure
hesham: 3GPP-2 haven't done with any of IPv6 thingy yet
(especially mobile-ip6)
soi: multiple document for 3GPP and 3GPP-2? should be fine.
sense of room
people willing to review/help improve document? (modulo design team)
- there are.
read? - a lot
accept as starting point? - a lot
should not accept as starting point? - none
ISP
scope of work
define the problem set of scenarios
core/backbone
broadband hybrid fiber coax/cable
broadband dslmnarrowband dialup
ethernet to the home/home networking
internet exchange points
security (detection/prevention)
network management
outline
toplogy
physical, logical
hardware
routers, switches, cpe
routing
igp, egp, irr, addressing, nat, aggregation
policing
filtering, traffic engineering
security
IDS, prevention
network management
out of band conf tools, snmp
hosting gear
DNS, radius, tacacs, mail, tools, cacheing
updates since IETF54
accepted as ngtrans wg document
01 draft submitted
detailed discussion on DSL
renamed to v6ops
remain personal draft until all sections filled in
added IX section
all sections should be filled in by IETF55
breakout
review outline
review existing document
itojun: DSL detail maybe too much
rob: DSL detail was helpful
unmanaged
scenario (scoping)
evaluation (analysis)
scope: exploring the problem space
applications
what are the application needs?
local, client, p2p, server
presented in yokohama
phases(X), stages(X), cases of transition
A: gateway is IPv4 only
B: gateway & ISP dual stack
C: gateway dual stack, ISP v4 only
D: gateway dual stack, ISP v6 only
A:
consensus - this is a real need, not all gateways can be easily upgraded
hosts ipv4 or dual stack
applications: client, p2p with outside
connectivity requirement
automatic tunnelling over UDP
aim for minimal server requirement
naming requirement
DNS access over v4
reverse lookup for client apps
B:
main line transition case
hosts: v4 only, dual stack, v6 only
apps:
local applications across the stacks
ipv6 only clients access ipv4 services
question mark: ipv4 client access ipv6 services
backward vs forward compatibility
p2p with outside = single stack
ipv6 servers accessible from outside
connectivity requirements
unmanaged network is dual stack
need "ipv6 prefix delegation" to gateway
some form of translation between local ipv4 and local ipv6
some form of translation between local ipv6 and global ipv4 services
naming requirements
name lookup service independent of protocol
dual stack home must get same answer if querying over v4 or v6
local applications must work
shadow of ipv4 only hosts in ipv6, and vice versa
not just a DNS issue (SLP, proprietary naming)
need to 'register' autoconfigured ipv6 addr
direct lookup (local/server apps)
reverse lookup (client apps)
rob: adhoc needs another analysis
bound: military case
hinden: military is more like adhoc?
?: some people don't consider it important to make v4-only and v6-only interwork. dualstack short-lived or long-lived?
rob: (some comment on v4/v6 interwork)
C:
mostly same requirement as case B
connectivity
gateway need to "self provision" a prefix, use some form of automatic tunnelling
naming
use DNSv4 for both A and AAAA lookup
may need to register with 3rd party service
need solution for reverse lookup
D:
case of "green field" isp
same appliation requirement as case B
connectivity
access to IPv4 internet through IPv6
this cannot be done with a gateway based system
namging
DNS access over ipv6
evaluation of mechanisms
still very sketchy
connectivity
A: teredo
B: RA proxy vs explicit delegation, variation of SIIT/NAT-PT
C: 6to4
D: network based variations of SIIT, DSTM
alain: NAT64?
rob: NAT-PT/SIIT/NAT64, what is same and what is different? they are basically the same beast.
naming
discovery of the DNS server by IPv6 hosts
DHCPv6, LLMNR, or reserved IPv6 addrss
local naming for IPv6 applications
dynamic update of server, or LLMNR
naming bridge for local applications
variation of NAT-PT, bridges to LLMNR, etc
access to IPv4 servers
configured SIIT prefix in IPv6 vs variations of NAT-PT
mechanisms, continued - breakout session!
wg item?
scenario document - accepted by ngtrans, reasonable to assume next revision gonna be wg item
?: design team consensus != wg consensus
mar: yes
shin: definition of "scope", prefix delegation/accounting could be ISP, or unmanaged home?
mar: all of groups will touch each other somewhere, somehow
(scenario only)
read? - alot
people willing to review/help improve document? (modulo design team)
- pretty good
accept as wg item? - alot
enterprise
still a young group, no way for this document to become wg item
what we have done?
definition of an enterprise
define our assumptions
what is our strategy?
discuss scenarios first
then point of transition
randy: who is administer network?
goals
focus on defining:
set of technology scenarios
set of transitioni mechanisms needed by different scenarios
set of tools needed for ipv6 deployment within the enterprise
focus on defining a template for
how existing/new transition mechanisms and tools could be used in the enterprise network scenarios
non-goals
(missed)
enterprise
connected to ISP
actively managed
multiple independent networks
may also have mobile ip users accessing network within the enterprise or from outside
enterprise can be
a large business
small office business
itojun: mobile-ip, does it mean mobile-ip, or roaming laptop?
huitema: remove protocol/techs while working on scenario. that biases your thought.
?: multihoming? - possible.
assumptions
rate/methods for adoption of ipv6 will vary
no one can tell users how to transition, they will all do it differently
some users have hardly any ipv4 addresses
some have plenty of them
some users will move right to ipv6 not later simply because it is easier
need to state our assumptions vs isp, unmanaged and 3gpp
though these will apply to the enterprise too
strategy
out initial consensus strategy is to discuss the scenarios first
then deal with the technical and transitional details below the scenarios
the following scenarios list is not complete
1:
enterprise, with an existing ipv4 network, wants to turn on ipv6 for a group of 100 clients that exist at two geographic sites
ipv6 clients need to commuinicate with each other , but still need access to ipv4 based services
what needs to be done to enable this deployment and where
which transitoin technology are applicable?
2:
enterprise, ipv4 existing, wireless services - optimize support mobile ip and choose to make this service ipv6 only
mobile ipv6 only node needs to still need access to ipv4 based services provided
3:
multi-site enterprise has deployed ipv4-nat withoverlapping private addrss ranges
to deploy peer-to-peer application deployed
they update OS to support both ipv4 and ipv6
what needs to be done to enable this deployment and where
which transition technologies are applicable as they begin using the application?
what chhanges or additional technologies are applicable when some isp for some site, but not all sites, offers native ipv6 service?
4:
more than one business unit, each unit run differently
one of the business unit decide wireless, p2p conferencing, and keep ipv4 apps
5:
two large enterprises using ipv4-nat merge with the consequence that large segments of private network address space overlap
to allow the network operations to merge they decide to deploy ipv6 across the network core and support infrastructure first
to further integrate the systems, what transition technologies are applicable to the end nodes?
plan of action
specify and define the scenarios in an incremental fashion
small network/single building/location
medium size/campus size/single location
larger network/campus environment/multiple location
wireless/mobiltiy incorporation (which fits into any of the previous casese)
specify points of transition
software points of transition
enterprise will be required to determine
what software will be extended
affected by transition
must be managed
this will define the policy for the enterprise
dns, routing, autoconf, security, application/api, address scoping, netman, address plan
tools for config
routing, dns, v4 address allloc, v6 address alloc, vpn/tunnel, mobile node
cellular - 8
ISP - 13
unmanaged - 8
enterprise - 16