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(a)serpens.de> -----
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
----------------------------------------------------------------------
FYI.
Regards,
Thomas Trede
-----Original Message-----
From: Internet-Drafts(a)ietf.org <Internet-Drafts(a)ietf.org>
To: IETF-Announce: ; <IETF-Announce: ;>
Cc: ipng(a)sunroof.eng.sun.com <ipng(a)sunroof.eng.sun.com>
Date: Mittwoch, 19. Mai 1999 15:15
Subject: (IPng 7550) I-D ACTION:draft-ietf-ipngwg-url-literal-00.txt
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>This draft is a work item of the IPNG Working Group of the IETF.
>
> Title : Preferred Format for Literal IPv6 Addresses in URL's
> Author(s) : B. Hinden, B. Carpenter
> Filename : draft-ietf-ipngwg-url-literal-00.txt
> Pages : 3
> Date : 18-May-99
>
>This document defines the preferred format for literal IPv6 Addresses
>in URL's for implementation in World Wide Web browsers. This format
>has been implemented in the IPv6 versions of several widely deployed
>browsers including Microsoft Internet Explorer and Mozilla.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-url-literal-00.txt
>
>Internet-Drafts are also available by anonymous FTP. Login with the
username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
> "get draft-ietf-ipngwg-url-literal-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
> mailserv(a)ietf.org.
>In the body type:
> "FILE /internet-drafts/draft-ietf-ipngwg-url-literal-00.txt".
>
>NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility. To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command. To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader. Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-url-literal-00.txt
Hi all!
My slides from the Presentation at RIPE 33 are now available under
http://engr.gigabell.net/ipv6/pres/
Greetings
Jan Czmok
Gigabell AG
Senior Network Engineer
