This whole thread is making me think that specifying that we use either babel 
(with attention to getting it documented properly) or one of the OSPFv4 MANET 
extensions, in the case where we have only a /64 and perhaps any time we find 
we have an 802.11s, ad-hoc or NBMA interface in play.  That way we introduce 
/128 routes, and everything continues to work.

Andrew

On 8/11/2012, at 10:51 AM, Brian E Carpenter <brian.e.carpen...@gmail.com> 
wrote:

> On 08/11/2012 15:09, Victor Kuarsingh wrote:
>>>>  even though this would destroy the benefits of subnetting.
>>> <RCC>I think it is arguable whether bridging is the least damaging
>>> solution. It fundamentally does not work with route-over multi-link
>>> subnets and would therefore require some extra L2 weirdness at a LLN
>>> border router. If ISPs are going to hobble us with /64s then I think you
>>> will find NPTv6 solutions appearing for the same reason NAT is used
>>> today. There are alternatives but, as noted in the architecture draft,
>>> these break SLAAC. So I think the onus is to push back on ISPs ofering
>>> /64s if we want to avoid any kludges.</RCC>
>> 
>> Just to further some of the comments I made yesterday.  I understand the
>> we donĀ¹t want a /64 to show up, but this may occur for reasons other then
>> the primary intention of the ISP.  Many things occur in a network - IP
>> depletion/low avail blocks, errors, mis-configuration etc.  No matter why
>> it occurs, ignoring this case is likely not a good idea.
>> 
>> I agree with earlier comments that this can be considered as a failure
>> mode.  It still needs to be considered for good engineering on how CPEs
>> and homenet gear will behave.
> 
> Exactly. It would be very bad for the end users to ignore this reality.
> 
> On 08/11/2012 15:02, Sander Steffann wrote:
> 
>>>> So let's just say that giving a single /64 to the home is incompatible 
>>>> with homenet architecture, and we need more addresses. I'm fine with that.
>> 
>> Yes please. I think some ISPs *need* to get a signal like this.
> 
> Sure, but that does *not* excuse us from specifying how the end user
> gets service in such a situation.
> 
>    Brian
> 
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to