draft minutes of the IPv6 wg at RIPE33

[David Kessens <]

Hi,

Please see below for the minutes of our session.

I would like to thank Petra Zeidler for being so kind to take the
minutes. Please send minor corrections directly to me.

I will declare the minutes with corrections final when no major
comments are received in two weeks from now.

David K.
---

----- Forwarded message from "S.P.Zeidler" spz@localhost -----

Minutes of the IPv6 WG meeting at RIPE 33

Agenda:

- Administrative Stuff
	Scribe is Petra Zeidler
	Agenda bashing was rather bashful (no changes)

- Status of 6BONE (presented by David Kessens)
	http://www.ip.qwest.net/~david/presentations/
	Questions:
	1) what about efforts to harden the 6BONE?
	   was being discussed at the last IETF, see minutes of that
	2) what's the status of 6REN?
	   6REN was being in full progress, and one should contact Bob Fink
	   for specifics

- IPv6 in practice (presented by Jan Czmok)
        http://engr.gigabell.net/ipv6/pres/
	Questions:
	1) what was the difficulty with multi-homing?
	   unresolved issue as to how to do that with customer-type address
	   ranges
	2) why was porting applications to IPv6 so important?
	   "Bump-in-the-stack" exists, but one reason to go to IPv6 right now
	   are the IPv6 network client configuration niceties
	3) there are reverse DNS tools for IPv6, why was this considered a problem?
	   The current tools need too much know-how, they're not "customer-safe"
	4) which applications needed porting the most?
	   those that users won't want to do without in the context of using
	   the Internet, i.e. mainly web browsers
	5) (Comment, rather) IPv6 over IPv4 with dynamically assigned
	   addresses wasn't a problem any more with the availability of the
	   tunnel brokers.
	
- European developments and initaitives regarding IPv6 (audience)
	- Bernard Tuy was working on IPv6 over ATM and can be contacted
	regarding that
	- Wilfried Woeber reported having held a presentation about a test
	program lately.
	An IPv6 native backbone in Europe would be desirable, one should look 
	out for 6EIX and also see the developments until September.
	Deploying IPv6 in a production environment would be more an 
	administrative than a technical problem.
	- Francis Dupont asked who actually used IPv4 non-tunneled multicast
	and if the current lack of IPv6 multicast capabilities in the current
	IPv6 Cisco IOS was perceived as a problem
	- IPv6 should be on the terminal-LAN of RIPE 34 as well

- IPv6 allocation progress (presented by Miriam Kuehne)
	see slides for the talk
	Discussion:
	- the documentation mentions default-free zones, a definition ought to
	be added
	- Q: Allocations are based on track record, why not use IPv4 address
	usage track record? A: the two need not necessarily compare
	- Q: why mention the future possible end of this Sub-TLA-space in the
	document? A: Decision processes slow down, one should be kept aware that
	new provisions will have to have been taken by then
	- Q: what is the term of the policy? A: it will be under constant
	review
	- Q: how would one get IPv6 customers or peerings without address
	space? A: in the beginning one'd have gotten space by the bootstrap
	procedures, or via 6BONE, later through ones upstream
	- Q: are the numbers (>= 3 peerings, >= 42 customers) ok? A: there was
	no dispute that 42 was the answer
	- Q: why have 2 valid reasons to get space currently, wouldn't the
	latter suffice? A: it should give those considering a request a frame
	of for what size a Sub-TLA would be seen appropriate; also, it's a
	heirloom from the ARIN allocation policy
	- a rewording of "immediate intent" was suggested, as it sounded none
	too realistic
	- Q: is further delay in the accepting of the policies expected?
	A: Not really, there were unwritten parts, but that shouldn't stop
	starting out.
	- Q: are there essential parts that should go in before this becomes
	policy? A: there were no objections to go ahead with the current state
	of the document
	- Q: was there input on the missing sections? A: -
	- address space not being owned by the assignee ought to be worded
	more clearly
	- "you might be required to renumber in the future" was very vague,
	suggestion to clarify that to: "in order to continue taking part in
	the Internet a renumbering may be neccessary for technical reasons".
	- the policy should reference the appropriate IETF documents
	- Q: why bother to slow-start S-TLAs? A: in order to get a range of
	prefix-lengths
	- Q: how long will the period to comment the policy be? A: not much
	longer
	- this policy is a common product of all the RIRs and will be shared
	
	
Action points:

33.1 RIPE NCC and the other regional registries will finalize the
     allocation draft document and start allocating IPv6 addresses as
     soon as possible
    	
----------------------------------------------------------------------