[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: memo, 1st day PM
Hello Itojun,
Fred Templin here - I don't currently have access to my work e-mail
so I'm using a private e-mail account.
I noticed an item missing from your "memo, 1st day PM" during Yanick's
enterprise/managed talk. At the end of the talk, I noted that during the
Yokohama IETF Tim Gleeson offered our document entitled "ISATAP Transition
Scenario for Enterprise/Managed Network" for the enterprise team and that
I subsequently re-iterated the offer. Yanick responded in the affirmative
and mentioned that a document from Paul Gilbert from cisco had also been
offered. I asked whether the team had examined the ISATAP document for
possible text reuse, and Yanick responded that the document was still
on the table.
Thank you,
Fred Templin
osprey67@yahoo.com
P.S. (In case you are wondering, the "osprey" is my favorite bird because
it is the most skilled of all fishing hawks, and fishing is my favorite
activity. "67" is my high school football jersey number, as can only be
told by checking P. 146 of the 1979 class yearbook from Dallas High School
in Dallas, PA.)
--- Jun-ichiro itojun Hagino <itojun@iijlab.net> wrote:
> [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
=== message truncated ===
__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com