Subject: draft-narten-ipv6-3177bis-48boundary-02.txt

From: Thomas Narten <[email-masked]>
Date: Wed, 12 Jul 2006 09:26:27 -0400

FYI, draft-narten-ipv6-3177bis-48boundary-02.txt was submitted just
prior to the ID cutoff, and the authors believe it is ready for
publication as an RFC. We are in discussion with the ADs about having
the document shepherded through the IESG as an informational document.
Note that this document would formally replace RFC3177.

Comments welcome of course!

Thomas

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 13 Jul 2006 00:54:35 +0200

> Comments welcome of course!

I think this should head to the IESG. Upon re-reading it I found one  
small issue though.

> 3.  Other RFC 3177 considerations
>
>    RFC3177 suggested that some multihoming approaches (e.g., GSE)  
> might
>    benefit from having a fixed /48 boundary. This no longer appears to
>    be a consideration. There is no such requirement coming out of the
>    IETF multi6 or shim6 efforts.

I think we can take the last sentence out. Mostly as we are seeing  
several parallel solutions being pursued and deployed, such as shim6,  
PI space and more specific PAs.

I don't believe this should go into the document, but I will also  
offer the observation that in some of the RIR regions the end-site  
allocation size have impacts on the LIRs relationship to the RIR -  
and this 'rule' has the potential for creating artificial complexity  
in that area.

- kurtis -

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Jul 2006 04:27:28 +0300 (EEST)

> Note that this document would formally replace RFC3177.

There have already been a lot of comments I agree with, so I'll just 
mention one higher-level issue that hasn't been mentioned yet 
(AFAICS):

This document obsoletes 3177, but does not mention those aspects of 
3177 which are not addressed by this document.  Silently leaving them 
out is bound to raise questions later on, so this document should make 
an explicit statement one way or the other.  Specifically, at least 
the discussion on /128 is missing.

Btw, the document title should probably say assignment instead of 
allocation.

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

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jul 2006 06:12:36 -0400

Folks,

I believe today in trying to be silent in IETF WG meetings unless it is
truly urgent technical issue I have as individual with a spec.  I am
sending this mail as I believe Tim Chown work on Campus transition
should be a working group document. I think it is good operational
example and brings out discussion of VLANs too which is important and
many other operational requirements other forms of deployment will face.

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-chown-v6ops-camp
us-transition-03.txt

Thanks
/jim

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 13 Jul 2006 16:16:24 +0200

On 13 jul 2006, at 15.36, Thomas Narten wrote:

> Kurt,
> So here is the dilemma. I put in this sentence because 3177 argues
> that /48 might be useful in the  context of multihoming/GSE. A while
> back, I asked multi6 whether this was the case and got a "no" back in
> response. Pekka (in another thread) complains that this document
> doesn't address all the points that 3177 did. So, if I take the above
> out, then what can I (usefully) say about the above point?

Well, first of all there will never be a solution out of multi6 (And  
the WG is to be closed :-) ), so that is an error. But I am more  
worried about only addressing this particular solution while there  
are clearly others being deployed. Note that I am not arguing about  
the first two sentences quoted above i.e "RFC3177 suggested that some  
multihoming approaches (e.g., GSE) might   benefit from having a  
fixed /48 boundary. This no longer appears to be a consideration.". I  
think that should address moving 3177 to historic - no? Maybe you  
could add "There are several solutions either being worked on or  
deployed for multihoming today, neither of which would benefit from a  
fixed /48 boundary".

>> I don't believe this should go into the document,
>
> Why not? Is it incorrect, or just unnecessary?

See above. I think it exclusive and should be rewritten.

>> but I will also
> what do you mean by "this rule"? That there is no longer a fixed /48
> can be used? If so, I agree, but the RIRs are already heading in that
> direction and I view it ias inevitable because we will eventually see
> end sites that need more than a /48, in which case we have to figure
> out how to count/measure/justify them.

By 'rule' I meant /48 for end-sites so I think we agree.

- kurtis -

---

From: Thomas Narten <[email-masked]>
Date: Thu, 13 Jul 2006 10:19:32 -0400

> think that should address moving 3177 to historic - no?

OK, I get it now. I'm happy to remove the last sentence then.

> By 'rule' I meant /48 for end-sites so I think we agree.

Ah, nothing like having a 'violent agreement'. :-)

Thomas

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Jul 2006 17:30:16 +0300 (EEST)

On Thu, 13 Jul 2006, Thomas Narten wrote:
> Can you please be specific about what points you think need to be
> carried over into 3177bis?

It is not clear to me why the arguments for a fixed boundary have been 
removed.  I accept that there is no IETF architectural issue whether 
the size is /48, /56 or whatever, but there would still be benefits 
for at least having a uniform guideline within a RIR.  Clearly some of 
those tradeoffs (e.g., no need to evaluate the need by the customer) 
are still valid.  Are you arguing that as the specific prefix length 
(within constraints) is not an IETF issue, we should also be quiet 
about the tradeoffs, in particular the reasons why the previous 
recommendation was the way it was?

Other than that, the current document mentions a number of times 
"subject to IPv6 architectural and operational considerations".  This 
is a new formulation, and it is not obvious to me what the 
architectural (or operational) considerations are.  There is some 
text regarding IPv6 standards but it is not clear whether these are 
the architectural considerations referred to here, and whether the 
current list of standards is exclusive.

Does the document mean (without saying it explicitly)  that assigning 
/128's to the users is NOT in the purview of the RIRs because the IETF 
IPv6 architecture defines the subnet boundary at /64?  Does it imply 
something else in addition/instead?

> Note that both references are in the specific "recommendation" part
> Yet, making a specific recommendation is exactly what this document is
> not doing. Can you say something about what you think would be
> appropriate to say about /128?

Per above.  For example, one could explicitly state what the IETF 
architectural considerations mean in this context.  E.g., this 
document does not give a warrant to assign addresses beyond /64, like 
as /128s.

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jul 2006 10:45:04 -0400

That works yes sorry I did not glean that one.
/jim 

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]] 
> Sent: Thursday, July 13, 2006 7:50 AM
> To: Bound, Jim
> Cc: [email-masked]
> Subject: Re: WG Document Question on 
> draft-chown-v6ops-campus-transition-03
> 
> I believe that the outcome of yesterday's meeting was that he 
> would divide it into two documents, one stable and one 
> ongoing, the stable one would be a working group document, 
> and would be published as informational by the WG following 
> appropriate discussion.
> 
> On Jul 13, 2006, at 6:12 AM, Bound, Jim wrote:
> 
> > Folks,
> >
> > I believe today in trying to be silent in IETF WG meetings 
> unless it 
> > is truly urgent technical issue I have as individual with a 
> spec.  I 
> > am sending this mail as I believe Tim Chown work on Campus 
> transition

---

From: Tim Chown <[email-masked]>
Date: Thu, 13 Jul 2006 16:27:59 +0100

> document does not give a warrant to assign addresses beyond /64, like 

From the home user point of view, as a customer, I would like:

1) At least a /60, given what I have today.
2) A fixed fee (no more 'ah a fixed IP is $10 more sir')
3) A static allocation
4) Moving to a different provider I will get the same size allocation
5) To use ULAs if/when their buglets are ironed out
6) To (when CPEs allow it) source and use IPv6 multicast services

Not having a fixed /48's may lead to differential charging (#2) for 
different offerings and potentially variation between providers(#4),
thus agreement on something is important.  A /56 is ample for actual
subnet use today.

I note that at least one tunnel broker product does not support /56 
size allocations cleanly.   That would need to change.   Users migrating
from 6to4 would have a smaller size allocation, so should form internal
address plans with that in mind for when they 'go native' (if they want
to keep the same topology and subnetting).

I think 3177 could mention static allocatiobns ( I don't see it in there).
This impacts address space consumption by the ISP, but I think is worth
including.

Regarding ULAs, I guess there would be some 'feature' of the CPE that
generates a /48 ULA under fd00::/8.  If we recommend a /56, what should
that CPE do?  Just use address space out of a 40-bit random allocation
with the other 8 bits zero?   ULAs were designed with an 'everyone uses
/48' view in mind.

On multicast, I can still generate unicast prefix based group addresses 
and even an embedded-RP address, as I can do for any /64, so that's OK.

-- 
Tim/::1

---

From: Fred Baker <[email-masked]>
Date: Thu, 13 Jul 2006 07:49:53 -0400

I believe that the outcome of yesterday's meeting was that he would  
divide it into two documents, one stable and one ongoing, the stable  
one would be a working group document, and would be published as  
informational by the WG following appropriate discussion.

---

From: Thomas Narten <[email-masked]>
Date: Thu, 13 Jul 2006 09:48:51 -0400

> 3177 which are not addressed by this document.

Pekka, you've raised this issue before, and I've gone back to 3177 and
tried to include (in 3177bis) the points from 3177 that actually make
sense (to me) to say something about. E.g., there is a lot of the text
in 3177 about multihoming that IMO is pretty irrelevant and there is
not much point in trying to include it.

> Silently leaving them 

3177 has no "discussion" about /128. What it says about /128 is the
following. Quoting from 3177:

   The IESG and the IAB recommend the allocations for the boundary
   between the public and the private topology to follow those general
   rules:

      -  /48 in the general case, except for very large subscribers.
      -  /64 when it is known that one and only one subnet is needed by
         design.
      -  /128 when it is absolutely known that one and only one device
         is connecting.

and then later...

   In particular, we recommend:

      -  Home network subscribers, connecting through on-demand or
         always-on connections should receive a /48.
      -  Small and large enterprises should receive a /48.
      -  Very large subscribers could receive a /47 or slightly shorter
         prefix, or multiple /48's.
      -  Mobile networks, such as vehicles or mobile phones with an
         additional network interface (such as bluetooth or 802.11b)
         should receive a static /64 prefix to allow the connection of
         multiple devices through one subnet.
      -  A single PC, with no additional need to subnet, dialing-up from
         a hotel room may receive its /128 IPv6 address for a PPP style
         connection as part of a /64 prefix.

And note for context, that the revised ARIN policy in this regard
doesn't even mention /128 anymore
(http://www.arin.net/policy/proposals/2005_8.html) the recommendation
there would appear to say that a /64 is the recommended minimum. Thus,
IMO, we really don't need to be very concerned about /128 to end
sites. No one seems (in practice) seems to think this is something
that ought to be done.

> Btw, the document title should probably say assignment instead of 

Indeed! Thanks.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 13 Jul 2006 09:36:53 -0400

Kurt,

Thomas

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 14 Jul 2006 13:28:51 -0700

> Comments welcome of course!

This document is not ready for publication and MUST NOT bypass the WG
consensus process. It is effectively an end run around consensus as it
suggests in the acknowledgments that it represents RIR discussions, though
fails to mention that no consensus exists. 

It purports to replace RFC 3177, but does so based on arbitrary preferences
to placate the hyper-conservation focused few rather than the considered
technical arguments in the established architectural recommendation. It does
not justify any specific changes in the math that 3177 used to highlight
that there are no technical reasons for other end site allocation units.
Instead it prefers to use hype and FUD such as 'excessive' and 'premature
depletion' without substantiation. This is despite the fact that one of the
co-authors own presentations in the referenced RIR discussions shows that
without this change current RIR practice would appropriately manage the pool
for around 500 years. This is far from 'premature', and is based on IPv4
trends which are gated on host growth rate rather than the IPv6 allocations
based on the substantially lower number of subnets. 

A specific note in the introduction argues that we need the suggested change
'for the long-term health and scalability of the public routing
infrastructure' without any reference to the impact that multiplicative
expansion and fragmenting the smaller public allocations would have. It
should be clear that by following this suggestion the potential to seriously
expand the size of and number of fragments in the public routing system far
exceeds any value that would be gained from the self stated 'more
conservative approach'. In the public RIR discussions there has not been a
clear consensus. The suggested conservation is misguided as the bits will be
wasted by replacement of the protocol which will occur for other than
depletion reasons long before we hit the 500 year mark. It uses the argument
of 'waste' by looking at the current end user deployment models rather than
recognizing that by opening up the space new deployment options become
available. This effort essentially amounts to an attempt to exercise control
over what end users are allowed to do by making them beg for each increment
of an abundant resource. 

This document argues that the goals 'could' be met in other ways, but does
not justify why they 'need' to be, or even show an assurance that they
'would' be. In fact it recognizes that renumbering subnets is still a
serious problem, then suggests in 4.1 that it is no big deal to just limit
the network topology to the assumed smaller allocation that would be the
result of this document. There is no discussion about the fragmentation that
would occur when a network outgrows its original space and would rather push
complexity into the global routing system rather than renumber. 

In section 2 it mentions that multiple prefix management is an issue,
suggesting that they all be the same length to reduce complexity, but there
is no discussion on how that would occur if providers choose arbitrary
allocation sizes. There appears to be an implied 'trust me' that it will all
work out and be possible for sites to get the same prefix lengths from
different providers. 

Also in section 2 it mentions in passing that the PTR tree is something to
consider, but does not spell out that managing that zone file across
multiple parties would be problematic and therefore recommend that forward
and reverse delegations be done on a nibble basis. It does provide more at
the very end of the summary, but still does not provide guidance on what
issues need 'adequate consideration'.

Referencing Multi6 & Shim6 seem out of place given that one produced nothing
and the other is producing something that is not deployable in real networks
where firewalls will kill the connections when the locators are changed. 

The entire effort is misguided in that 3177 is a recommendation based on
architectural balance, while this document is nothing more than ambiguous
FUD intended to shift parceling control from the end site network to the
ISP/RIR. It is presented under the guise of conservation in the routing
system simply to give cover to those that want to deviate from 3177, though
in fact it effectively balloons the routing system through fragmentation
spread over even more bits. There is no hard and fast boundary, and 3177
makes itself very clear that it is just a recommendation. If the RIRs want
to establish a different policy they can, though there is no architectural
justification for it.

RFC 3177 could use a tune-up, but it is not clear if opening the document is
worth the effort. The one thing that is clear is that this document is not a
replacement for it in any sense of the word. 

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Jul 2006 23:49:22 +0200

...
> removed.  I accept that there is no IETF architectural issue whether the 
> size is /48, /56 or whatever,

Having had a lot to do with the text of 3177, I have been reluctantly
forced to the conclusion that those arguments have been overtaken by
events. I think the drafts explains why, too. And the draft doesn't
need to explain why its arguments are somewhat vague instead of being
firm recommmendations - it really isn't in the IETF's scope to
make such recommendations, now that the IPv6 unicast space is being
administered by the RIRs.

I'm personally sorry to see /48 not applied universally but that bus
has left.

      Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 18 Jul 2006 16:32:32 +0200

Hi Brian,

I don't think the /48 bus has left ... May be you can explain the reason/s
why you think so ?

Regards,
Jordi

> De: Brian E Carpenter <[email-masked]>
> Organización: IBM
> Responder a: <[email-masked]>
> Fecha: Sat, 15 Jul 2006 23:49:22 +0200
> Para: Pekka Savola <[email-masked]>
> CC: Thomas Narten <[email-masked]>, <[email-masked]>
> Asunto: Re: draft-narten-ipv6-3177bis-48boundary-02.txt
> 
> ...
>> 

**********************************************
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.