Brian E Carpenter wrote:
> Stephen,
>
> Can you explain why people think there is any need to allocate anything
> longer than a /48 in the first place?
>
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 [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]
> > --------------------------------------------------------------------
--
------------------------------------------------------------------------
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"
------------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
