Subject: RE: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Fri, 7 Jul 2000 22:07:56 +1000

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 [email-masked]
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-masked]
> > > Reply-To: [email-masked]
> > > To: [email-masked]
> > >
> > > [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-masked]>. 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-masked]>
> > >                                                      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-masked] *
> > --
------------------------------------------------------------------------
> > Stephen Burley         "If patience is a virtue, and ignorance is
bliss,
> > UUNET EMEA Hostmaster            you can have a pretty good life
> > [email-masked]            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-masked]
> > --------------------------------------------------------------------

--
------------------------------------------------------------------------
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"
------------------------------------------------------------------------

---

From: Richard Draves <[email-masked]>
Date: Fri, 7 Jul 2000 10:44:14 -0700

> IMHO, the problem lies with using /64 for the default subnet size;

I was thinking something similar... if an ISP gave me a /64, I would just
modify the stateless addr conf code to allow it to be subnetted. Once you
have code to support pseudo-random interface identifiers (for the privacy
draft), allowing variable sized interface identifiers is pretty easy.

Rich

---

From: "C. R. Kalmanek" <[email-masked]>
Date: Mon, 10 Jul 2000 12:08:26 -0400

We need to do anything we can to facilitate aggregation, since 
(assuming there are enough addresses) this will be the thing that 
most hinders scalability.  I don't know where we stand today with 
respect to being able to handle all the routes in the default free 
zone, but we don't want to make things worse.  

Since there appear to be enough addresses, either the current 
option (/48 only) or an option that allows either /48 or /56 seem 
like the best choices.  Having an movable boundary anywhere between
/48 and /64 will definitely hurt aggregation and site mobility.

That said, with the current option, having 64K subnets for the 
network in my car seems like a bit of overkill.  This is a
case that seems to stretch the definition of a "site" in the
current addressing architecture...

chuck