Re: [v6ops] disconnected homenets

[Alexandru Petrescu <[e-mail]>]

Le 23/06/2014 17:18, Tim Chown a écrit :
>
> On 23 Jun 2014, at 15:56, Alexandru Petrescu <[e-mail]> wrote:
>
>> Old email, sorry.
>>
>> Le 28/05/2014 23:24, Mark ZZZ Smith a écrit :
>> [...]
>>> The use case I like to imagine is a home user streaming a video from
>>> their NAS to their TV over their internal network. That should use
>>> ULAs so that a failure of their Internet connection/Global addressing
>>> has no impact on watching their movie. If the movie failed because
>>> the Internet connection/global addressing failed, that user will call
>>> the ISP's helpdesk. But why should it fail! The home users internal
>>> network is fine, it is only external connectivity that has failed.
>>
>> I hope this requirement is considered in the homenet architecture discussion.
>
> It is already covered, e.g. in 3.4.2.

Thanks, it's already covered and makes sense.

However, I have one minor issue with it.

I do not understand why it requires an in-home Router to not advertise 
self as a default router whenever ULA prefixes are involved.

>    In cases where ULA prefixes are in use within a homenet but there is
>    no external IPv6 connectivity (and thus no GUAs in use),
>    recommendations ULA-5, L-3 and L-4 in RFC 6204 should be followed to
>    ensure correct operation, in particular where the homenet may be
>    dual-stack with IPv4 external connectivity.  The use of the Route
>    Information Option described in [RFC4191] provides a mechanism to
>    advertise such more-specific ULA routes.

(or I can't remember the earlier discussions).

It may be that this requirement will make the in-home Hosts not capable 
of talking to each other simply because not implementing RFC4191.  And, 
certainly RFC4191 is not for Router-to-Router communications.

The benefit of the doubt.

Alex

>
> Tim
>
>>
>> Too often the in-home Internet-disconnected network can not work internally.
>>
>> Alex
>>
>>>
>>> People might argue that enterprise networks are different and they
>>> are - they're simpler! Enterprise networks have technical staff on
>>> hand that can troubleshoot networks and resolve faults. If you can
>>> make IPv6 work seamlessly for home networks and their non-technical
>>> "operators", you've solved the harder problem. Since enterprise
>>> networks also value the same things home networks do - seamless
>>> operation, robustness against failure, stable internal connectivity,
>>> you've solved most of the enterprise network problems too.
>>>
>>>> It doesn't conform to RFC 7084 either, which clearly
>>>
>>>> states that "prefix(es) (and ULA prefix if configured...)" must be
>>>> advertised.
>>>>
>>>
>>> The precursor to 7084 (6204) was in development at the time, but it
>>> wouldn't have helped because they were ignoring our feedback.
>>> (Another CPE vendor was much better and almost too keen - they were
>>> sending me new software to test within 24 hours after reporting an
>>> IPv6 issue.)
>>>
>>> Regards, Mark.
>>>
>>> _______________________________________________ v6ops mailing list
>>> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>
>