[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

memo, 1st day PM

[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