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

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 12-jul-2006, at 9:30, Thomas Narten wrote:

> draft-narten-ipv6-3177bis-48boundary-02.txt
I have several problems with this document.

It's vague. RFC 3177 is very clear and provides easily identifiable  
recommendations supported by arguments. The new draft doesn't provide  
any recommendations to speak of, other than that /48 is probably too  
much for most users. It then sort of tosses the issue over the fence  
into RIR terrain, largely ignoring the importance of maintaining the  
same assignment size when moving from one service provider to  
another, which is a prominent consideration in RFC 3177.
I don't think it would be the worst idea ever for the authors to  
simply retract the document and for the IETF to stand by RFC 3177.
In the alternative, I strongely suggest using RFC 3177 as a model for  
the new document and only insert new text where required by new  
insights, maintaining the overal clarity of the ealier document. It  
should be stressed that having different prefix sizes in the market  
place leads to higher operational cost because moving from one ISP to  
another then requires doing more work than just change a fixed number  
of high bits in all places where addresses appear in configurations.
I'd like to offer the way DHCPv6 prefix delegation is implemented in  
Cisco routers as an example. Cisco routers are capable of requesting  
a prefix over DHCPv6 and then automatically generate addresses for  
subnets based on this prefix. However, this requires adding a  
specific number of bits, so even though the prefix itself doesn't  
appear in a router configuration, its _length_ does.
Obviously it's easier to renumber from a small prefix into a larger  
one, but if different prefix sizes exist it can't be assumed that the  
only movement is from service providers giving out long ones to  
service providers giving out shorter ones.
There is another issue, that is not present in the original RFC 3177,  
but which I stumbled over several times in operational environments,  
so I think it's important it's addressed:
RFC 3177 only talks about the prefix for the end-user. It doesn't  
address the way the end-user communicates with his or her service  
provider. (I'm ignoring the case of a /128.) With a /64 this can  
happen in one of two ways:
1. The ISP assigns the /64 for use on the link between the ISP and  
the user
2. The ISP hands the /64 to the user for internal use

In the first case, the user can't let the device that talks to the  
ISP route IPv6 between an internal subnet and the ISP, but is forced  
to connect all devices that require connectivity directly at the link  
level to the ISP.
In the second case, there aren't any addresses available on the link  
between the user and the ISP, so either additional address space must  
be provisioned, or link locals must be used. Neither of these is  
impossible, but they do require additional complexity that is  
extremely undesireable.
Considering the above, giving out /64 really doesn't address a  
reasonable use case: either the prefix is used on the ISP link and  
then a /128 would also suffice, or the prefix isn't used on the ISP  
link and a second subnet is required.
For these reasons, I think it's important to move away from /64 in  
the RFC 3177 /128-/64-/48 model. The next obvious choice is /60,  
which allows for 16 subnets. The all-ones subnet [1] could be used  
for the ISP subnet by convention, simplifying address provisioning  
and leaving 15 subnets for use by the customer. This is more than  
enough in all cases where only a single router is expected to be  
present on the site in question.
This brings us to a /128-/60-/48 model. The next question is whether  
it's useful to bring the /48 down to /56 as a general recommendation.  
My answer is no. Since for the vast majority of home and small office  
users a /60 will suffice where they would have gotten a /48 under RFC  
3177 (because they have a handful of subnets or in case they will in  
the future), the amount of address space used will already go down  
dramatically, so from an address use point there is no reason to  
fiddle with /48. A second argument is that if someone needs more than  
a /60, there is a reasonable chance that they may eventually also  
grow out of a /56. If and when that happens, they have up to 250  
subnets and renumbering at that point is quite painful, apart from my  
earlier argument about the virtue of having a standardized prefix  
size for a given class of end-users.
Iljitsch van Beijnum

[1] Another choice would be the all-zeros subnet but if the same is  
done with a /48 it would be a shame to use this subnet up for this as  
the all-zeros subnet allows for shorter addresses, especially if more  
zeros follow.