Transition Mechanisms for
IPv6 Hosts and Routers

draft-ietf-ngtrans-mech-v2-00.txt

Jun-ichiro itojun Hagino, KAME/IIJ research lab
(because Erik is absent)

itojun@{kame,iijlab}.net

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

What have changed since RFC2893?

	Remove reference to A6, retain AAAA
	Remove automatic tunnel and IPv4 compatible addr (::x.y.z.u)
	Remove default configured tunnel using IPv4 "anycast address"
	Remove source address selection
		-> separate document
	Remove mention of 6over4

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Issues raised in draft/on mailing list (1)

	Should 6to4 be mentioned?
	Should all DNS stuff be removed?
		duplicate of addr-select
		some discussion on mailing list

	wording nits, section reordering (templin)
	unidir tunnel really worth a mention? (pekka)
	is TOS field handling friendly with DSCP? (pekka)
	more security consideration (pekka, alain, itojun)
		injecting packet into egress point (anonymiehze)
		auto tunnel will be open relay of packet

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Issues raised in draft/on mailing list (2)

	tunnel MTU/MRU needs to be specified, PMTUD rule should be simplified (itojun)
		referenced from 6to4/ISATAP documents, should it be separate?
	biased to dual stack operation, should talk about IPv6-only operation (alain)
	real meaning of "dual stack"? (alain)
	ingress filtering at tunnel egress and IPv4 anycast address (alain)
	how about separating document into two? (itojun)
		tunnel doc, and dual stack doc

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

What to do next?

	It is clear we need another revision
	Interested in working on it further? (sense of room)
	Should it become v6ops wg item? (sense of room)
			(6) Assume responsibility for advancing the basic IPv6 transition mechanism RFCs along the standards track, if their applicability to common deployment solutions is demonstrated in (5) above:
			This includes updating these mechanisms, as needed, to resolve problems.  In some cases, these mechanisms may be deprecated (i.e. moved to Historic), if they are not found to be applicable to the deployment solutions described in (5) or if serious flaws are encountered that lead us to recommend against their use.
	Take the issue to mailing list, and continue onto Atlanta
		(assuming Erik shows up) 

-end