[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[sig-ipv6] BOUNCE sig-ipv6@lists.apnic.net: Non-member submission from ["Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>]
>From owner-sig-ipv6 Fri Jul 7 22:09:46 2000
Received: from ish7.ericsson.com.au ([203.61.155.111])
by whois.apnic.net (8.9.3/8.9.3) with ESMTP id WAA94236
for <sig-ipv6@apnic.net>; Fri, 7 Jul 2000 22:09:45 +1000 (EST)
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8])
by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id WAA28764;
Fri, 7 Jul 2000 22:07:04 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165])
by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id WAA13723;
Fri, 7 Jul 2000 22:08:09 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21)
id <3FW9RWGX>; Fri, 7 Jul 2000 22:07:58 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB0FF@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'Stephen Burley '" <stephenb@uk.uu.net>,
"'Brian E Carpenter '"
<brian@hursley.ibm.com>
Cc: "'Kazu@venus.Sun.COM '" <Kazu@venus.Sun.COM>,
"'Yamamoto@venus.Sun.COM '" <Yamamoto@venus.Sun.COM>,
"'ipng@sunroof.eng.sun.com '" <ipng@sunroof.eng.sun.com>,
"'ngtrans@sunroof.eng.sun.com '" <ngtrans@sunroof.eng.sun.com>,
"'arano@byd.ocn.ad.jp '" <arano@byd.ocn.ad.jp>,
"'sig-ipv6@apnic.net '"
<sig-ipv6@apnic.net>,
"'mir@ripe.net '" <mir@ripe.net>, "'joao@ripe.net '" <joao@ripe.net>
Subject: RE: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision
Date: Fri, 7 Jul 2000 22:07:56 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01BFE80B.FC30E3D0"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01BFE80B.FC30E3D0
Content-Type: text/plain
VERY true IMO
Call me oldfashioned but i remember when people thought we had enough
space in IPv4
and it would never run out. If you fix the boundry at a /48 it means an
ISP will go
through their block of addresses way too fast. It also means that out
customers do
not have to think about what they are deploying as they know they will
get a /48 no
matter what. So a flexible boundry between /48 and /64 would help us to
help
customers to think about how they will deploy their address space. A /64
for dialup
is also too rigid because the way technology is going a /64 is not going
to be
enough subnets for what wiill be a dial up connection with a large lan
behind it.
Just my thoughts.
>
> Brian
>
> Stephen Burley wrote:
> >
> > "Kazu Yamamoto (山本和彦)" wrote:
> >
> > > Folks,
> > >
> > > It seems to me that RTRs are going a wrong way, changing /48 per
site
> > > policy. If you think so, please speak up on sig-ipv6@apnic.net
now.
> > >
> > > --Kazu
> >
> > Hi
> > We discussed it at length in the RIPE 36 meeting and the
majority not all
> > were not in favour of not fixing the boundries but rather allowing
the LIR to
> > decide on merit/justification what amount of space to assign whithin
the /48 -
> > /64 boundries. If we fixit to /48 /56 /64 boundries it becomes too
rigid, allow
> >
> > the LIR's to dictate their own assignment policy (ie flexible or
fixed at 3
> > points /48 /56 /64) which they can justify to the RIR, in this way
it pleases
> > everyone - i garuntee if you fix the boundries it will have to be
re-addrressed
> >
> > later on and will not please all.
> >
> > My thoughts
> > Stephen Burley
> > UUNET EMEA Hostmaster
> >
> > >
> > >
> > >
------------------------------------------------------------------------
> > >
> > > Subject: [apnic-announce] IPv6 Policy Document Revision
> > > Date: Wed, 5 Jul 2000 17:24:24 +1000 (EST)
> > > From: secretariat@apnic.net
> > > Reply-To: apnic-talk@apnic.net
> > > To: apnic-announce@lists.apnic.net
> > >
> > > [Note "reply-to:" field]
> > >
> > > Summary
> > >
> > > Both ARIN and the RIPE NCC have had discussions with the Internet
> > > communities in their region concerning the size of address
prefixes
> > > to be assigned to IPv6 end sites. APNIC is now seeking input from
> > > the community in the Asia Pacific region on this issue. If you
care
> > > about this, please read on.
> > >
> > > Some background
> > >
> > > The existing IPv6 policy document 'Provisional IPv6 Assignment and
> > > Allocation Policy Document' was published in May 1999. Formal
revision
> > > of the document commenced in October 1999. The existing document
> > > is available at:
> > >
> > > http://www.apnic.net/drafts/ipv6/ipv6-policy-280599.html
> > >
> > > Feedback on the existing document was collected from the Internet
community
> > > at large facilitated through the regional processes of
consultation by
> > > the RIRs as well as input from the membership of the 6bone and the
> > > IETF IPv6 working groups. The deadline for comments was 31st
January 2000.
> > >
> > > On 29th March, the RIRs, chairs of the IPv6 related IETF working
> > > groups and 6bone particpants met in Adelaide. The purpose of the
meeting
> > > was to expand and elaborate in person on the comments made by the
> > > IAB/IETF/6bone concerning the existing policy document.
> > >
> > > One of the issues of concern that had been previously raised by
> > > members is the size of the end-site prefix (the 'SLA ID',
currently
> > > defined in rfc2374 as 16 bits at a /48). This includes *all* types
> > > of end-sites including a single device. A /48 is sufficient
address
> > > space to create 64K of subnets.
> > >
> > > The technical motivation for the 16 bit SLA ID field and the
> > > 'one size fits all' principle was described in rfc2374 as:
> > >
> > > "The size of the Site-Level Aggregation Identifier field is 16
bits.
> > > This supports 65,535 individual subnets per site. The design
goal
> > > for the size of this field was to be sufficient for all but the
> > > largest of organizations. Organizations which need additional
> > > subnets can arrange with the organization they are obtaining
Internet
> > > service from to obtain additional site identifiers and use this
to
> > > create additional subnets.
> > >
> > > The Site-Level Aggregation Identifier field was given a fixed
size in
> > > order to force the length of all prefixes identifying a
particular
> > > site to be the same length (i.e., 48 bits). This facilitates
> > > movement of sites in the topology (e.g., changing service
providers
> > > and multi-homing to multiple service providers)."
> > >
> > > It is possible to imagine in future a variety of types of
end-sites
> > > being connected to the Internet. Some of these devices will be
part
> > > of routed networks and others will not. The question proposed is
whether
> > > 'one size fits all' (the /48) is appropriate for all end-sites?
> > >
> > > Both the RIPE and ARIN communities have rejected this.
> > >
> > > APNIC has been asked to consult with the Internet community in the
> > > Asia Pacific on this issue.
> > >
> > > To date, there has been no consensus on what alternatives should
be
> > > taken, but 3 different approaches have been identified in addition
to
> > > the 16 bit SLA ID field specified in rfc2374.
> > >
> > > These are:
> > >
> > > 1) /64 for single devices (such as mobile phones), /48 for all
other sites
> > >
> > > 2) /64 for single devices, /48 for large end sites which need more
> > > than 256 subnets, and /56 for other sites (eg small,
domestic/home sites)
> > >
> > > 3) Assign what is needed for the forseeable needs of the site, as
a
> > > variable-length prefix of between /48 and /64. (It is important
to
> > > remember that for any site that becomes multi-homed it is
necessary to
> > > use equal length prefixes from each provider even in the case
where
> > > one provider has allocated more prefix space than the other).
> > >
> > > We are interested in your opinions, so that we may convey this to
the
> > > other RIRs and to the IETF community. Please direct all follow up
> > > discussion and comments to <sig-ipv6@apnic.net>. For details of
> > > how to subscribe to this mailing list, please visit our web site
at:
> > > http://www.apnic.net/general.html#mailing-lists .
> > >
> > > + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + +
> > > APNIC Secretariat
> > > <secretariat@apnic.net>
> > > Tel:
+61-7-3367-0490
> > > Asia Pacific Network Information Centre (APNIC) Ltd Fax:
+61-7-3367-0482
> > > Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia
> > > + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + +
> > >
> > > * APNIC-ANNOUNCE: Announcements concerning APNIC
*
> > > * To unsubscribe, send "unsubscribe" to
apnic-announce-request@apnic.net *
> >
> > --
> >
------------------------------------------------------------------------
> > Stephen Burley "If patience is a virtue, and ignorance is
bliss,
> > UUNET EMEA Hostmaster you can have a pretty good life
> > Stephenb@uk.uu.net if you're stupid and willing to wait"
> >
------------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPng Working Group Mailing List
> > IPng Home Page: http://playground.sun.com/ipng
> > FTP archive: ftp://playground.sun.com/pub/ipng
> > Direct all administrative requests to majordomo@sunroof.eng.sun.com
> > --------------------------------------------------------------------
--
------------------------------------------------------------------------
Stephen Burley "If patience is a virtue, and ignorance is bliss,
UUNET EMEA Hostmaster you can have a pretty good life
[SB855-RIPE] if you're stupid and willing to wait"
------------------------------------------------------------------------
------_=_NextPart_001_01BFE80B.FC30E3D0
Content-Type: text/html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>VERY true IMO</FONT>
</P>
<BR>
<BR>
<P><FONT SIZE=2>Call me oldfashioned but i remember when people thought we had enough</FONT>
<BR><FONT SIZE=2>space in IPv4</FONT>
<BR><FONT SIZE=2>and it would never run out. If you fix the boundry at a /48 it means an</FONT>
<BR><FONT SIZE=2>ISP will go</FONT>
<BR><FONT SIZE=2>through their block of addresses way too fast. It also means that out</FONT>
<BR><FONT SIZE=2>customers do</FONT>
<BR><FONT SIZE=2>not have to think about what they are deploying as they know they will</FONT>
<BR><FONT SIZE=2>get a /48 no</FONT>
<BR><FONT SIZE=2>matter what. So a flexible boundry between /48 and /64 would help us to</FONT>
<BR><FONT SIZE=2>help</FONT>
<BR><FONT SIZE=2>customers to think about how they will deploy their address space. A /64</FONT>
<BR><FONT SIZE=2>for dialup</FONT>
<BR><FONT SIZE=2>is also too rigid because the way technology is going a /64 is not going</FONT>
<BR><FONT SIZE=2>to be</FONT>
<BR><FONT SIZE=2>enough subnets for what wiill be a dial up connection with a large lan</FONT>
<BR><FONT SIZE=2>behind it.</FONT>
</P>
<P><FONT SIZE=2>Just my thoughts.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<P><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>> Brian</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>> Stephen Burley wrote:</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > "Kazu Yamamoto (山本和彦)" wrote:</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > > Folks,</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > It seems to me that RTRs are going a wrong way, changing /48 per</FONT>
<BR><FONT SIZE=2>site</FONT>
<BR><FONT SIZE=2>> > > policy. If you think so, please speak up on sig-ipv6@apnic.net</FONT>
<BR><FONT SIZE=2>now.</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > --Kazu</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > Hi</FONT>
<BR><FONT SIZE=2>> > We discussed it at length in the RIPE 36 meeting and the</FONT>
<BR><FONT SIZE=2>majority not all</FONT>
<BR><FONT SIZE=2>> > were not in favour of not fixing the boundries but rather allowing</FONT>
<BR><FONT SIZE=2>the LIR to</FONT>
<BR><FONT SIZE=2>> > decide on merit/justification what amount of space to assign whithin</FONT>
<BR><FONT SIZE=2>the /48 -</FONT>
<BR><FONT SIZE=2>> > /64 boundries. If we fixit to /48 /56 /64 boundries it becomes too</FONT>
<BR><FONT SIZE=2>rigid, allow</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > the LIR's to dictate their own assignment policy (ie flexible or</FONT>
<BR><FONT SIZE=2>fixed at 3</FONT>
<BR><FONT SIZE=2>> > points /48 /56 /64) which they can justify to the RIR, in this way</FONT>
<BR><FONT SIZE=2>it pleases</FONT>
<BR><FONT SIZE=2>> > everyone - i garuntee if you fix the boundries it will have to be</FONT>
<BR><FONT SIZE=2>re-addrressed</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > later on and will not please all.</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > My thoughts</FONT>
<BR><FONT SIZE=2>> > Stephen Burley</FONT>
<BR><FONT SIZE=2>> > UUNET EMEA Hostmaster</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>------------------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > Subject: [apnic-announce] IPv6 Policy Document Revision</FONT>
<BR><FONT SIZE=2>> > > Date: Wed, 5 Jul 2000 17:24:24 +1000 (EST)</FONT>
<BR><FONT SIZE=2>> > > From: secretariat@apnic.net</FONT>
<BR><FONT SIZE=2>> > > Reply-To: apnic-talk@apnic.net</FONT>
<BR><FONT SIZE=2>> > > To: apnic-announce@lists.apnic.net</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > [Note "reply-to:" field]</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > Summary</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > Both ARIN and the RIPE NCC have had discussions with the Internet</FONT>
<BR><FONT SIZE=2>> > > communities in their region concerning the size of address</FONT>
<BR><FONT SIZE=2>prefixes</FONT>
<BR><FONT SIZE=2>> > > to be assigned to IPv6 end sites. APNIC is now seeking input from</FONT>
<BR><FONT SIZE=2>> > > the community in the Asia Pacific region on this issue. If you</FONT>
<BR><FONT SIZE=2>care</FONT>
<BR><FONT SIZE=2>> > > about this, please read on.</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > Some background</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > The existing IPv6 policy document 'Provisional IPv6 Assignment and</FONT>
<BR><FONT SIZE=2>> > > Allocation Policy Document' was published in May 1999. Formal</FONT>
<BR><FONT SIZE=2>revision</FONT>
<BR><FONT SIZE=2>> > > of the document commenced in October 1999. The existing document</FONT>
<BR><FONT SIZE=2>> > > is available at:</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > <A HREF="http://www.apnic.net/drafts/ipv6/ipv6-policy-280599.html"; TARGET="_blank">http://www.apnic.net/drafts/ipv6/ipv6-policy-280599.html</A></FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > Feedback on the existing document was collected from the Internet</FONT>
<BR><FONT SIZE=2>community</FONT>
<BR><FONT SIZE=2>> > > at large facilitated through the regional processes of</FONT>
<BR><FONT SIZE=2>consultation by</FONT>
<BR><FONT SIZE=2>> > > the RIRs as well as input from the membership of the 6bone and the</FONT>
<BR><FONT SIZE=2>> > > IETF IPv6 working groups. The deadline for comments was 31st</FONT>
<BR><FONT SIZE=2>January 2000.</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > On 29th March, the RIRs, chairs of the IPv6 related IETF working</FONT>
<BR><FONT SIZE=2>> > > groups and 6bone particpants met in Adelaide. The purpose of the</FONT>
<BR><FONT SIZE=2>meeting</FONT>
<BR><FONT SIZE=2>> > > was to expand and elaborate in person on the comments made by the</FONT>
<BR><FONT SIZE=2>> > > IAB/IETF/6bone concerning the existing policy document.</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > One of the issues of concern that had been previously raised by</FONT>
<BR><FONT SIZE=2>> > > members is the size of the end-site prefix (the 'SLA ID',</FONT>
<BR><FONT SIZE=2>currently</FONT>
<BR><FONT SIZE=2>> > > defined in rfc2374 as 16 bits at a /48). This includes *all* types</FONT>
<BR><FONT SIZE=2>> > > of end-sites including a single device. A /48 is sufficient</FONT>
<BR><FONT SIZE=2>address</FONT>
<BR><FONT SIZE=2>> > > space to create 64K of subnets.</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > The technical motivation for the 16 bit SLA ID field and the</FONT>
<BR><FONT SIZE=2>> > > 'one size fits all' principle was described in rfc2374 as:</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > "The size of the Site-Level Aggregation Identifier field is 16</FONT>
<BR><FONT SIZE=2>bits.</FONT>
<BR><FONT SIZE=2>> > > This supports 65,535 individual subnets per site. The design</FONT>
<BR><FONT SIZE=2>goal</FONT>
<BR><FONT SIZE=2>> > > for the size of this field was to be sufficient for all but the</FONT>
<BR><FONT SIZE=2>> > > largest of organizations. Organizations which need additional</FONT>
<BR><FONT SIZE=2>> > > subnets can arrange with the organization they are obtaining</FONT>
<BR><FONT SIZE=2>Internet</FONT>
<BR><FONT SIZE=2>> > > service from to obtain additional site identifiers and use this</FONT>
<BR><FONT SIZE=2>to</FONT>
<BR><FONT SIZE=2>> > > create additional subnets.</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > The Site-Level Aggregation Identifier field was given a fixed</FONT>
<BR><FONT SIZE=2>size in</FONT>
<BR><FONT SIZE=2>> > > order to force the length of all prefixes identifying a</FONT>
<BR><FONT SIZE=2>particular</FONT>
<BR><FONT SIZE=2>> > > site to be the same length (i.e., 48 bits). This facilitates</FONT>
<BR><FONT SIZE=2>> > > movement of sites in the topology (e.g., changing service</FONT>
<BR><FONT SIZE=2>providers</FONT>
<BR><FONT SIZE=2>> > > and multi-homing to multiple service providers)."</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > It is possible to imagine in future a variety of types of</FONT>
<BR><FONT SIZE=2>end-sites</FONT>
<BR><FONT SIZE=2>> > > being connected to the Internet. Some of these devices will be</FONT>
<BR><FONT SIZE=2>part</FONT>
<BR><FONT SIZE=2>> > > of routed networks and others will not. The question proposed is</FONT>
<BR><FONT SIZE=2>whether</FONT>
<BR><FONT SIZE=2>> > > 'one size fits all' (the /48) is appropriate for all end-sites?</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > Both the RIPE and ARIN communities have rejected this.</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > APNIC has been asked to consult with the Internet community in the</FONT>
<BR><FONT SIZE=2>> > > Asia Pacific on this issue.</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > To date, there has been no consensus on what alternatives should</FONT>
<BR><FONT SIZE=2>be</FONT>
<BR><FONT SIZE=2>> > > taken, but 3 different approaches have been identified in addition</FONT>
<BR><FONT SIZE=2>to</FONT>
<BR><FONT SIZE=2>> > > the 16 bit SLA ID field specified in rfc2374.</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > These are:</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > 1) /64 for single devices (such as mobile phones), /48 for all</FONT>
<BR><FONT SIZE=2>other sites</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > 2) /64 for single devices, /48 for large end sites which need more</FONT>
<BR><FONT SIZE=2>> > > than 256 subnets, and /56 for other sites (eg small,</FONT>
<BR><FONT SIZE=2>domestic/home sites)</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > 3) Assign what is needed for the forseeable needs of the site, as</FONT>
<BR><FONT SIZE=2>a</FONT>
<BR><FONT SIZE=2>> > > variable-length prefix of between /48 and /64. (It is important</FONT>
<BR><FONT SIZE=2>to</FONT>
<BR><FONT SIZE=2>> > > remember that for any site that becomes multi-homed it is</FONT>
<BR><FONT SIZE=2>necessary to</FONT>
<BR><FONT SIZE=2>> > > use equal length prefixes from each provider even in the case</FONT>
<BR><FONT SIZE=2>where</FONT>
<BR><FONT SIZE=2>> > > one provider has allocated more prefix space than the other).</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > We are interested in your opinions, so that we may convey this to</FONT>
<BR><FONT SIZE=2>the</FONT>
<BR><FONT SIZE=2>> > > other RIRs and to the IETF community. Please direct all follow up</FONT>
<BR><FONT SIZE=2>> > > discussion and comments to <sig-ipv6@apnic.net>. For details of</FONT>
<BR><FONT SIZE=2>> > > how to subscribe to this mailing list, please visit our web site</FONT>
<BR><FONT SIZE=2>at:</FONT>
<BR><FONT SIZE=2>> > > <A HREF="http://www.apnic.net/general.html#mailing-lists"; TARGET="_blank">http://www.apnic.net/general.html#mailing-lists</A> .</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +</FONT>
<BR><FONT SIZE=2>+ + + +</FONT>
<BR><FONT SIZE=2>> > > APNIC Secretariat</FONT>
<BR><FONT SIZE=2>> > > <secretariat@apnic.net></FONT>
<BR><FONT SIZE=2>> > > Tel:</FONT>
<BR><FONT SIZE=2>+61-7-3367-0490</FONT>
<BR><FONT SIZE=2>> > > Asia Pacific Network Information Centre (APNIC) Ltd Fax:</FONT>
<BR><FONT SIZE=2>+61-7-3367-0482</FONT>
<BR><FONT SIZE=2>> > > Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia</FONT>
<BR><FONT SIZE=2>> > > + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +</FONT>
<BR><FONT SIZE=2>+ + + +</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > * APNIC-ANNOUNCE: Announcements concerning APNIC</FONT>
<BR><FONT SIZE=2>*</FONT>
<BR><FONT SIZE=2>> > > * To unsubscribe, send "unsubscribe" to</FONT>
<BR><FONT SIZE=2>apnic-announce-request@apnic.net *</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > --</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>------------------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>> > Stephen Burley "If patience is a virtue, and ignorance is</FONT>
<BR><FONT SIZE=2>bliss,</FONT>
<BR><FONT SIZE=2>> > UUNET EMEA Hostmaster you can have a pretty good life</FONT>
<BR><FONT SIZE=2>> > Stephenb@uk.uu.net if you're stupid and willing to wait"</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>------------------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > --------------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>> > IETF IPng Working Group Mailing List</FONT>
<BR><FONT SIZE=2>> > IPng Home Page: <A HREF="http://playground.sun.com/ipng"; TARGET="_blank">http://playground.sun.com/ipng</A></FONT>
<BR><FONT SIZE=2>> > FTP archive: <A HREF="ftp://playground.sun.com/pub/ipng"; TARGET="_blank">ftp://playground.sun.com/pub/ipng</A></FONT>
<BR><FONT SIZE=2>> > Direct all administrative requests to majordomo@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=2>> > --------------------------------------------------------------------</FONT>
</P>
<P><FONT SIZE=2>--</FONT>
<BR><FONT SIZE=2>------------------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>Stephen Burley "If patience is a virtue, and ignorance is bliss,</FONT>
<BR><FONT SIZE=2>UUNET EMEA Hostmaster you can have a pretty good life</FONT>
<BR><FONT SIZE=2>[SB855-RIPE] if you're stupid and willing to wait"</FONT>
<BR><FONT SIZE=2>------------------------------------------------------------------------</FONT>
</P>
<BR>
</BODY>
</HTML>
------_=_NextPart_001_01BFE80B.FC30E3D0--
* sig-ipv6: APNIC SIG on IPv6 technology and policy issues *
* To unsubscribe: send "unsubscribe" to sig-ipv6-request@apnic.net *
