Stephen,
Can you explain why people think there is any need to allocate anything
longer than a /48 in the first place?
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
> > Reply-To: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> >
> > [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 <[EMAIL PROTECTED]>. 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
> > <[EMAIL PROTECTED]>
> > 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 [EMAIL PROTECTED] *
>
> --
> ------------------------------------------------------------------------
> Stephen Burley "If patience is a virtue, and ignorance is bliss,
> UUNET EMEA Hostmaster you can have a pretty good life
> [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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 [EMAIL PROTECTED]
--------------------------------------------------------------------
