Subject: draft-ietf-v6ops-addcon WGLC

From: Fred Baker <[email-masked]>
Date: Sun, 3 Dec 2006 13:15:01 -0800

This is to announce a working group last call of http:// 
tools.ietf.org/html/draft-ietf-v6ops-addcon

Please read the draft at this time, noting spelling or wording issues  
to the authors and substantive issues to the authors copying the list.

Working Group last call will close in two weeks.

---

From: Ginny Listman <[email-masked]>
Date: Wed, 6 Dec 2006 09:03:07 -0500

> Working Group last call will close in two weeks.

I had the Registration Services folks here at ARIN review the document, 
as they are more aware of the address assignment considerations that I
am. The only comment is as follows:

IPv6 Unicast Address Assignment Considerations writes:

2.4.1.  Sizing the Network Allocation

   We do not discuss here how a network designer sizes their application
   for address space.  By default a site will receive a /48 prefix [8].
   The default provider allocation via the RIRs is currently a /32 [28].
   These allocations are indicators for a first allocation for a
   network.  Different sizes may be obtained based on the anticipated
   address usage [28].  There are examples of allocations as large as
   /19 having been made from RIRs to providers at the time of writing.

The second sentence isn't really true in the ARIN policy set. Our policy 
recommends:

"/56 for small sites, those expected to need only a few subnets over the 
next 5 years."

cf. http://www.arin.net/policy/nrpm.html#six54

The second sentence should be either struck or amended to reflect /56 for 
the ARIN region.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 06 Dec 2006 12:29:58 -0200

I thin the text is correct if you read it considering the reverence to
RFC3177.

However, an alternative wording may be something such as:

... By default a site will receive a /48 prefix [8], however different RIR
service regions policies may suggest alternative default assignments or let
the ISPs to decide on what they believe is more appropriate for their
specific case.

Also, for section 3.3.4 I want to suggest some rewarding, as it seems to
somehow "priorize" /126 for point-to-point links. I will use:

   The 126 bit subnet prefixes are typically used for point-to-point
   links similar to the RFC3021 [5] recommendations for IPv4.  The usage
   of this subnet address length does not lead to any additional
   considerations other than the ones discussed earlier in this section,
   particularly those related to the "u" and "g" bits. The 126 bit subnet
prefixes aren't the only alternatives for this, as frequently other sizes
such as 64, 112, etc., are also used (reference to
draft-palet-v6ops-point2point-01, which is being updated soon also).

Last, but not least, I will much prefer that migration is not used in the
document (5.2.3.4), and instead transition or transition/co-existence is
used.

Regards,
Jordi

> De: Ginny Listman <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Wed, 6 Dec 2006 09:03:07 -0500
> Para: Fred Baker <[email-masked]>
> CC: <[email-masked]>, <[email-masked]>, <[email-masked]>
> Asunto: Re: draft-ietf-v6ops-addcon WGLC
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 06 Dec 2006 12:37:04 -0200

Sorry, typing too fast ...

Obviously it was "I think the text is correct if you read it considering the
reference to RFC3177."

Regards,
Jordi

------ Mensaje reenviado
De: JORDI PALET MARTINEZ <[email-masked]>
Responder a: <[email-masked]>
Fecha: Wed, 06 Dec 2006 12:29:58 -0200
Para: <[email-masked]>
Conversación: draft-ietf-v6ops-addcon WGLC
Asunto: Re: draft-ietf-v6ops-addcon WGLC

Regards,
Jordi

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of this
information, including attached files, is prohibited.

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of this
information, including attached files, is prohibited.

------ Fin del mensaje reenviado

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

---

From: Fred Baker <[email-masked]>
Date: Mon, 18 Dec 2006 16:19:47 -0500

On Dec 3, 2006, at 4:15 PM, Fred Baker wrote:
> Please read the draft at this time, noting spelling or wording  
> issues to the authors and substantive issues to the authors copying  
> the list.
>

The WGLC on this officially closed yesterday. There is one particular  
comment that has not been made and which our friendly neighborhood AD  
would like to hear made - presumably by people who need to depend on  
reading the document. Let me put this generally and ask for specific  
operational response.

Do you (ARIN, RIPE, etc, and operational folks) consider the document  
to be well written and to provide useful guidelines to its intended  
audience?

---

From: Pekka Savola <[email-masked]>
Date: Tue, 19 Dec 2006 15:40:04 +0200 (EET)

On Sun, 3 Dec 2006, Fred Baker wrote:
> This is to announce a working group last call of 
> http://tools.ietf.org/html/draft-ietf-v6ops-addcon
>
> Please read the draft at this time, noting spelling or wording issues to the 
> authors and substantive issues to the authors copying the list.
>

Sorry for being a few days late, but writing up the comments took a 
while.  I think the doc is in pretty good shape.

I'd recommend moving the case studies to an appendix.

Substantial
-----------

A multihomed
    host may thus have two addresses, one per prefix (provider), and
    select source and destination addresses to use as described in that
    RFC. [...]

==> it seems that more text is required of this; maybe an additional
paragraph with pointers.  Specifically, making address selection and ingress
filtering work at the border requires some action from the site
administrator as discussed in a couple of Internet-drafts out of multi6 and
shim6 WGs.  The current text makes this sound a bit too easy..

    An allocation of a prefix shorter then 64 bits to a node or interface
    is bad practice.  The shortest subnet prefix that could theoretically
    be assigned to an interface or node is limited by the size of the
    network prefix allocated to the organization.

==> However, there is at least one valid case of a prefix shorter than /64:
the 6to4 pseudo-interface which should have a /16.  Maybe this should be
mentioned for completeness.

    In addition it is discouraged to assign a matching embedded-RP IPv6
    address to a device that is not a real Multicast Rendezvous Point.

==> personally, I don't see a major problem with this.  No application or
host should (IMHO) have an assumption that if the RIID is pingable
(or some other similar criterion), it would be an RP.  Personally I wouldn't
assign RIID = 1 (which probably the most common Embedded-RP RIID value used)
to a host though, but that's for other reasons..

3.3.4.  /126 addresses

    The 126 bit subnet prefixes are typically used for point-to-point
    links similar to the RFC3021 [5] recommendations for IPv4.

==> I'm not sure if RFC3021 is directly comparable to v4 /31, especially
because /126 allows for more addresses.  /126 seems to be more like a v4
/30.  Given that the use of /31 required modifications to specifications,
I'm not sure how relevant that is in this context given that there is no
shortage of v6 addresses for p2p links.

    Basic design decisions for the exemplary Service Provider IPv6
    address plan regarding customer prefixes take into consideration:
    o  The prefixes assigned to all customers behind the same LER (e.g.
       LER or LER-BB) are aggregated under one prefix.  This ensures that
       the number of labels that have to be used for 6PE is limited and
       hence provides a strong MPLS label conservation.
...
    When the IPv6 customer address pool of a LER (or another device of
    the aggregation network - AG or RAR) is exhausted, the related LER
    (or AG or RAR) prefix is shortened by 1 or 2 bits (e.g. from /38 to
    /37 or /36) so that the originally reserved growing zone can be used
    for further IPv6 address allocations to customers.  In the case where
    the growing zone is exhausted as well a new prefix range from the
    corresponding pool of the next higher hierarchy level can be
    requested.

==> These two points in particular raise the question of "umm.. what about
renumberability?"  If a customer changed the RAR, LER or whatever, would it
need to renumber?  If a RAR, LER, etc. would need to be split up (e.g., due
to needing a bigger device), would some need to renumber?  Etc.  You already
discuss this in 5.2.3.3. but this at least needs to be referred to, if not
discussed a bit (i.e., how does that affect the design?).  Today
in many cases, e.g., customer ADSL lines, customers will need to renumber
but corporate customers (even if they used the same ADSL infrastructure)
wouldn't.  This seems the minimum model that needs to be supported by IPv6
deployments IMHO.

Editorial
---------

==> In abstract, rephrase two instances of "draft" (no longer applicable when
this is an RFC)

    The address assignment considerations are analyzed separately for the
    two major components of the IPv6 unicast addresses, namely 'Network
    Level Addressing' (the allocation of subnets) and the 'Subnet Prefix'
    (address usage within a subnet).

==> 'Subnet Prefix' seems to be a misnomer in this context, as it usually
refers to a prefix, not the interface-ID part of the address.  Was this a
typo?

Finally the document provides two examples of
    successfully deployed address plans in a service provider (ISP) and
    an enterprise network.

==> I'd remove "successfully" because these deployments haven't really seen
the "test of time" yet, i.e., we don't yet know if the planning has been
successful because IPv6 hasn't been thoroughly deployed yet.

However
    ARIN is now piloting PI address space allocations, subject to
    customers meeting certain requirements.

==> no longer 'piloting' I think..

   This format implies that when selecting subnet prefixes longer then
    64, and the bits beyond the 64th one are none-zero, the subnet can
    not use embedded-RP.

==> s/none/non/

    For the Mobile IPv6 early trails, we have allocated one prefix for

==> s/trails/trials/

       is recommended.  (Note: A strong aggregation e.g. on POP,
       aggregation router or LER level limits the numbers of customer

==> spell out 'LER'.

       adapt changes that are injected from the customer side.  This
       covers changes to addressing architecture or routing topology that
       are triggered from for instance the raising needs of the customers
       regarding IPv6 addresses as well as changes that come from

==> s/raising/growing/ (or 'rising') ?

       *  A pool (e.g. /24) for satisfying the addressing needs of real
          "big" customers (as defined in 5.2.2.1 sub-section A.) that

==> s/real/really/ (or something like that)

    coded using a /64 prefix.  (Note: While it is suggested to chose a
    /48 for addressing the POP/location of the SP network it is left to

==> s/chose/choose/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings