Subject: Re: [v6ops] Some questions on draft-ma-v6ops-ipv6-address-assignment

From: joel jaeggli <[email-masked]>
Date: Wed, 20 Feb 2013 00:14:04 -0800

On 2/19/13 11:09 PM, maqiongfang wrote:
> Dear all,
> We have posted a draft about IPv6 address planning in the operator
> network, at http://tools.ietf.org/html/draft-ma-v6ops-ipv6-address-ass
> please make some comments. thanks!

Some thoughts.

So, this is pretty well traversed ground already. at a minimum a
document wading into area should characterize why it is different than
the previous documents and attempts to address the issue.

section 3, MiFi is a registered trademark of novatel wireless in the
united states and several other markets. the functionality you are
describing is that of a router or device supporting mobile tehering.

While I recognize that section 5 is a stab at a semantic address
assignment section 6 essentially rebuts the utility of the document by
stating that the problem is not genralizeable. in the example in section
5 the p1 bit-field which is the most significant bits in the prefix
assignment to the provider, is the type field, if a provider is assigned
a /16 then you just burned a /19 on loopbacks and interface addresses if
you use 3 bits for the type field, which seems like a lot.

---

From: "maqiongfang" <[email-masked]>
Date: Wed, 20 Feb 2013 17:53:57 +0800

Hi Joel,

Thanks for your comments.

I agree with you that using the word "MiFi" is not good. In section 3, what I mean here is devices allows sharing the Internet connection of the phone or tablet with other devices such as laptops. 

In fact, this draft discussed the IPv6 address palnning. section 5 give an example to illustrate the address planning, in the example, how many fields the 64 bit can be divided into ,the length and meaning of each field should  be assigned according to the development of service and users. so I  stated that the assignment  is not genralizeable in section 6. 

I also think that using 3 bits for the type field is  too much, the extra fields can be conserved. As the number of users increasing, some fields may be not enough, the conserved fields can be used for expansion in the future.

Best wishes!

Ma Qiongfang

2013-02-20 

发件人： joel jaeggli 
发送时间： 2013-02-20  16:13:58 
收件人： maqiongfang; [email-masked]; draft-ma-v6ops-ipv6-address-assignment 
抄送： v6ops-chairs; IPv6 Ops WG 
主题： Re: Some questions on draft-ma-v6ops-ipv6-address-assignment 
 
Some thoughts.

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Feb 2013 08:55:28 -0800

Summary:

As written, I cannot support this draft. It is divergent from what I have come
to believe are the best practices for numbering IPv6 networks. This document
seems to incorporate a significant amount of IPv4-think and over-conservative
granularity in the initial sections, while providing contradictory and confusing
advice in section 5.

A more detailed description of my concerns:

Section 2 (3) I am unclear what you mean by the second bullet point.

Section 2(4) is similarly unclear to me.

Section 3 makes no allowance for the benefits of providing a uniform assignment size to all
subscribers. There is nothing wrong with assigning a /48 to each end-site and no reason
to discourage this practice.

Section 3(2) should be rewritten replacing MiFi with "Mobile Hotspot or other portable
on-demand router technology". I do not agree that such a device should receive only
a /60. I would support rewording to "at least a /60 and no more than a /48."

Section 3(3) I do not agree with limiting broadband CPE to /56. There is no reason
not to assign these devices a /48. I could accept tis draft if it were reworded to
"at least a /56 and no more than a /48."

Section 3(4) should be reworded to "a /48 per end-site where an end-site is
a single structure, building, or tenant in a multi-tenant structure or building".
There is no reason to count hosts in IPv6 and these words should be removed.
In IPv6, we should be counting subnets, not hosts.

Section 3(5) should be rewritten as "Loopback interfaces requiring public addresses
should, generally be assigned a /128. In certain applications, a shorter prefix may
be necessary or desirable."

Section 3(6) is very poorly constructed and implies that a datacenter should assign
a /127 to each server and connect each server separately to its upstream router.
While assigning /127s to point to point links can be an expediency to work around
certain security issues today, I do not support codifying it as a permanent 
recommendation. Rather I would prefer to see "Point to point links should be
assigned /64s, though it may be desirable to configure them as /127s to work
around certain security concerns." or words to that effect.

Section 4 paragraph 3 you have reversed LAN and WAN. The WAN requires
a /64 (or a /127) and the LAN requires a /48 (or less). Further, computing
the address pool as a combined total may not always yield optimal results.
There are good reasons to aggregate the LAN and WAN segments separately
in many cases as the WAN segments may be better aggregated across
multiple BRAS in a serving center, while each BRAS should have its own
aggregate pool of LAN addresses to allocate to subscribers. Further, I
believe it is good practice to round such pool assignments up to the next
nibble boundary which is neglected in this paragraph. A suggested rewrite:

The calculation of address pool in a broadband access server such
as a BRAS or CMTS is slightly more complicated. In the broadband
network, assume that user capacity configured in a BRAS is
roughly 30 thousand end-sites. Each end site needs a prefix from
which LAN segments can be assigned and a WAN interface address.
The WAN interface numbering must be deployed on both the CPE and
the provider's access gear and a single WAN interface prefix may be
shared among multiple subscribers. In the case where each WAN
segment contains a single subscriber, each segment should receive
a /64. In the case where multiple subscribers share a single segment,
a single /64 should be used for each shared segment. Each
subscriber should receive a /48 (or longer) prefix. The sum of the
expected number of prefixes (30 thousand in this case) should be
calculated as a number of bits (30,000 would round up to 32768
or 15 bits) and rounded up to a multiple of four (16 bits in this
case). This number should then be subtracted from the largest
prefix size to be issued (/48 for example would yield a /32).
The number of WAN segments should be similarly calculated
as a number of /64s (for example, let's say we put 200 subscribers
on a given WAN segment), this would be 30,000/200=150 /64s
or 8 bits. Since 8 is already a multiple of 4, no additional rounding 
is required. 64-8 is 56, so a /56 is required for WAN segments.
Thus, the example broadband server would receive a /32 for
subscriber addressing and a /56 for WAN segment numbering.

Section 5, it should be made clear that this is just one example of one
way to carve up addresses and may not be applicable to all networks.
In fact, I would argue that placing "type" at the highest level of aggregation
may be very undesirable in most deployments.

The assumption that all persons reading this document will receive
their global prefix from an LIR is also incorrect. Many will be receiving
directly from an RIR or (in AP region, NIR).

I have never seen a network where setting aside 1/2 of the address
space for network infrastructure and leaving only 1/2 of the address
space for customer assignments makes any sense at all. Thus, I
do not think that your P0 type flag description is supportable.

Further, it may not be desirable to use uniform sizes for all divisions
at this first level. Often, for example, it may be desirable to set aside
a chunk of address space for all oeprational infrastructure separate
from the address space used to meet client needs. For example,
let us consider a small ISP which has received 2001:db8::/32
from its RIR. It is common practice for such an ISP to take the
first /48 (2001:db8:0::/48 (or 2001:db8::/48)) for use in numbering
its infrastructure. It may take an additional /48 per manned site
for its own internal IT usage. From within the first /48, networks
would be created for DNS servers, network device loopback
addressing, web servers, DHCP servers, etc.

Your explanation of the P2 field is vague. A better description
might be that P2 is used to number separate instantiations
of the types of networks numbered in P1. In some cases, this
may indicate a subtype (extending the proposed metaphor).

P3 and P4 descriptions imply that geographical aggregation
is preferable to topological aggregation. I believe this is
entirely false and I would suggest that the terms Province
and City be replaced with the terms "Topological Region
and "Serving Site", respectively.

In P5, the term city should similarly be replaced with "Serving
Site".

Section 7, I believe there are no security conisderations
applicable to address assignment beyond those described
above.

Section 8, I don't see any IANA implications to this set of
recommended addressing practices.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 28 Feb 2013 01:38:10 -0800

On Feb 28, 2013, at 00:53 , "maqiongfang" <[email-masked]> wrote:

> Owen,
>  
> Thank you very much for your serious and long comments. There are some imprecise descriptions and wordings in the draft, and your comments help me to 
> make it clear. 
>  
> Section 2 the needs of management : address palnning should be easy to manage. for example, the lacation informantion or network type (wireless network, 
> wlan,) can be embodied in the address.
> The Qos of certain service have special requirements to the number of bits of address aggregation, so the address assignment should take the special 
> requiremnts into account. (this requirement is derived from IPv4, if IPv6 should also consider it? )
>  

These sound like you're overlapping the draft regarding semantic addressing.  I think that topic is better addressed in that draft.

> Section 3， we think that the number of users under mobile hotspot is fewer than in the home broadband， so we assign a shorter prefix without actual 
> user surveys. Maybe you are right that a /60 is a little less.

There is, IMHO, no reason to assign anything longer than a /48 to any end-site ever.
Whether it's a dorm room, a cell phone, an apartment, a single family detached home, a warehouse or a small business, there's no need to assign a long prefix.

A /60 is certainly too restrictive. A /56 might be OK for a few years, but probably won't last all that long. However, if we do standardize on these longer prefixes, we are likely to stifle innovation and creativity in the applications space for many years to come.

>  Section 4 ,thanks for your rewrite. I think the train of thoughts is different.  In the example, the 30 thousand users means home gateways , I assume 
> that each home gateway contains a single subscriber, each WAN segment receive a /64 and each subscriber receive a /56( or longer /48 as your advice). 
>  

/48 is shorter, not longer. Shorter prefix = larger network.

> You said that “put 200 subscribers on a given WAN segment”. Do you mean that subscribers of enterprise?
My DSL at my residence, for example, has a WAN segment that includes me and several other customers. It's addressed with an IPv4 /24. I presume if it were to have IPv6 capability, it would get a /64 to work along side the /24. My router has a single node address within that /24.
Other customers also have single node addresses within that /24. That is what I mean by 200 subscribers on a given WAN segment.

Obviously other topologies are possible, including 1 subscriber per WAN segment, in which case, a /64 for the WAN segment is still equally viable.

>  
> section5,              Maybe the figure caused some misunderstanding in this example. I do not mean to use uniform sizes for all divisions. The size of P0 is fixed and sizes of 
> other divisions are depended on the requirements of specific network and are not the same generally. 
>  
> I do not mean that The number of network address and the user's address is equal. The network address is generally far less than the user's address,
>  we may assign 4 bit for the type flag, wherein 1/16 for network infrastructure and other for customers or reserved.
>  

Yes, this is very unclear as written. I'm still not sure I am in complete agreement even with the concept presented, however.

Owen

>  
> many thanks and best regards.
>  
>  
> Qiongfang
>  
>  
> 2013-02-28
>  
> 发件人： Owen DeLong
> 发送时间： 2013-02-21  01:01:19
> 收件人： joel jaeggli
> 抄送： maqiongfang; [email-masked]; draft-ma-v6ops-ipv6-address-assignment; IPv6 Ops WG; v6ops-chairs
> 主题： Re: [v6ops] Some questions on draft-ma-v6ops-ipv6-address-assignment
> Summary:
>