I was thinking that, in an effort to reduce scope to something we can deal with 
for now, that a /64 would be big enough - and if this prefix is "globally 
available" on the internet, I think it's much more than the ISPs can get their 
heads around, at least for now.

I understand the limitations of stateless autoconfig and other constraints, but 
I would start with something like a /64, but with a capability that allows 
multiple /64 prefixes (or other method for SLAAC) to be added later without a 
forklift upgrade or re-thinking of what we do first.  Each home site "could" 
subnet this space, so we could include any new work on MDNSEXT or other name 
resolution that is decentralized but can cross subnets.

I don't think we would be short-changing potential uses for home net by taking 
IPv6 "baby steps" for now….given that the ISPs and consumer home networks are 
not even as advanced as the multi-service IPv4 home network business models we 
were trying to sell to LECs/CLECS/ISPs when I was at 2Wire back in 2000.

I (for one) would be thrilled if I could get an IPv6 /64 that is globally 
visible (not NAT'd) from my ISP.  It's so much more than I have today.

Randy


On Nov 13, 2012, at 2:47 PM, james woodyatt <[email protected]> wrote:

> On Nov 13, 2012, at 10:33 , Randy Turner <[email protected]> wrote:
> 
>> I've been away from the list for awhile, and am trying to catch up -- is 
>> there a reference or quick explanation as to why a "/64" assigned to a home 
>> network is considered to be potentially "constrained" somehow ?
> 
> Once upon a time [RFC 3177], we believed that creating a numbering plan for 
> subscriber networks was intolerably difficult and expensive, so we thought it 
> would be a very good idea to make sure every new subscriber of any size would 
> a /48 delegation, which we all thought was big enough for all but the most 
> titanic of organizations.  The idea was you'd get enough space up front that 
> you could take your numbering plan with you if you ever moved from one 
> provider to another.  Space was thought to be too cheap to meter, and the 
> benefit of number plan stability across providers was thought to be 
> beneficial.
> 
> Since then, we have discovered two things: A) service providers guard with 
> astonishing ferocity every last number they get from their registries even 
> when they are too cheap to meter, and B) the problem of number plan scaling 
> is one that only people without any money have any interest in seeing solved. 
>  Hence, we have a new recommendation from IAB [RFC 6177], which capitulates 
> on the one-size-fits-all recommendation. It also says this in section 2:
> 
>   However, this precludes the expectation that even home sites will
>   grow to support multiple subnets going forward.  Hence, it is
>   strongly intended that even home sites be given multiple subnets
>   worth of space, by default.  Hence, this document still recommends
>   giving home sites significantly more than a single /64, but does not
>   recommend that every home site be given a /48 either.
> 
> For my part, I have a hard time foreseeing how the expectation that 
> residential sites will always have more space to assign than a single /64 
> subnet is even remotely reasonable.  Far too many service providers are 
> casting into operational concrete topologies that assign only one subnet to 
> each billable subscriber gateway.
> 
> I don't hold out much hope that much of a market will ever exist for 
> residential networks with multiple subnets per subscriber.  I also don't hold 
> out much hope for the kind of coordination between service providers that 
> will permit multihomed residential sites to work well.
> 
> That's why it looks to me like HOMENET will eventually converge on specifying 
> single /64 links behind a single residential gateway.
> 
> 
> --
> james woodyatt <[email protected]>
> core os networking
> 
> _______________________________________________
> homenet mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/homenet
> 

_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to