[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: narten-ipv6-3177bis-48boundary: technical justification
- To: Thomas Narten <narten@us.ibm.com>
- Subject: Re: narten-ipv6-3177bis-48boundary: technical justification
- From: Brian E Carpenter <brian.e.carpenter@gmail.com>
- Date: Wed, 30 Jul 2008 19:29:38 +1200
- Cc: v6ops@ops.ietf.org
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=oJCzVpWYBHfxOys4zEzx4oUuRcjW5ZY4E3wGcVcjmtVVrzGDTFQydjkuDL2OSBE3rw ivxtEGDvE8C9UtCH8iZJw9j2AwKw5IP+p2FGz6iQEw8PGXKvI73/ksJSUL3YRa/nNGDb f3d5YABf0cyc/6jvteV/lFZ0tk1lyS3vE3bSU=
- In-reply-to: <200807252014.m6PKEA86011871@cichlid.raleigh.ibm.com>
- Organization: University of Auckland
- References: <200807252014.m6PKEA86011871@cichlid.raleigh.ibm.com>
- User-agent: Thunderbird 2.0.0.6 (Windows/20070728)
On 2008-07-26 08:14, Thomas Narten wrote:
> At the Philly meeting, Bob Hinden raised the following issue (my
> summary of his words):
>
>> completely agree with HD ratio. not in favor of this document in
>> current form. 1. I've not seen any analysis that the current /48
>> will result in running out of /48s. there was some analysis with
>> previous HD ration. But after changing HD ratio, would like to see
>> justification other than just "its too big". would like to see
>> technical analysis that there is a problem.
>
>> wants to see technical justification that the number needs to be
>> changed. unless there is technical problem to fix, no need to
>> change.
>
> IMO, this question gets back to "should we change the policy", i.e.,
> where should the actual boundary be. That is not an IETF question,
> that is for the RIRs to decide. I'm also not trying to make the case
> that it NEEDS to be changed in this document. (It is true that the
> RIRs have already changed the policy, because its members didn't like
> a /48 for everyone and also didn't like a one-size-fits all approach,
> regardless of what that default value would be).
>
> One of the "problems" that I'd like to see fixed is the IETF seeming
> to be on record as saying that a /48 is necessary and is part of the
> architecure. That is how RFC 3177 is being intepreted by some. I.e.,
> in RIR discussions about the boundary, it is fairly common for some
> folk to say "but the IETF said a /48 was necessary, therefore I don't
> think we should change it."
I agree. I think the IETF needs to get out of the road here. However,
I wonder if we can strengthen the wording about /64 a bit, to make
a clearer technical recommendation that /64 is too long in most
circumstances.
Also, I wonder whether we should have a few words for IANA, e.g.
7. IANA Considerations
This document makes no specific requests to IANA. However, in
setting its policy for delegating IPv6 address space to registries,
IANA should allow for the fact that the normal allocation to
subscribers will be a prefix shorter than /64.
I know that they know that, but it does no harm to be clear
that I can see.
Brian