Re: [mif] I-D draft-ietf-mif-dhcpv6-route-option-03 published

[Simon Perreault <[e-mail]>]

On 2011-09-12 09:30, Alexandru Petrescu wrote:
> Le 12/09/2011 15:12, Simon Perreault a écrit :
>> On 2011-09-11 06:36, maximilien mouton wrote:
>>> I thus think that a client should be able to require only a
>>> default route (and no other route).
>>
>> Why? What's the use case?
> 
> CErtainly there are exist use cases for machines using only default
> route, and no other route.  Typically with single-interfaced Hosts.
> 
> One particular example is the typical office desktop PCs, which are
> typically leafs to the Internet, and only browse web; the net appliances.
> 
> Another is typical PDA, cellphone, smartphone which only has a default
> route and no specific route to its neighbors (operator typically opposes
> this, because needs to charge uniformly).

What you're describing is typical usage. I agree that the typical usage
will be default routes, but there is no harm if these devices receive
specific routes. Both of these examples typically have a regular routing
table and can install and use specific routes. So where's the harm if
they receive specific routes?

>> Are you working with hosts that do not have a generic routing table
>> and only support a single default route?
> 
> I am not sure about the term generic routing table... I think most Hosts
> which support routes, support several of them, and several of default
> routes.
> 
> But, one may think about the very small platforms which have very little
> memory and may hold a very limited number of routes... in these cases
> the default route is the one kind of route which allows it to reach the
> widest number of other Hosts in the Internet (every other non-default
> but specific route helps it reach a smaller number of Hosts).
> 
> What do you think?

I don't see the use case. Can't the DHCP client on the very small
platform just install the default route first, then whatever other
routes it can support, and ignore the rest?

The number of routes will also be limited by MTU, so it will end up
being very low anyway.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca