#7: separate specific routes from default routes? draft-ietf-mif-dhcpv6-route- option-04
Comment (by alexandru.petrescu@…): On 12-03-27 13:56, Alexandru Petrescu wrote: > Dear participants in MIF WG, > > Currently draft-ietf-mif-dhcpv6-route-option-04 specifies a way for the > DHCPv6 Server to communicate a set of routes to the DHCPv6 Client. This > covers both specific routes and the particular case of default routes (a > default route is meant when the RT_PREFIX option is absent, or > alternatively by using 128 0 bits as RT_PREFIX). > > I think this is an issue. > > It's not good to have two different things to achieve the same > functionality. Agree. There used to be two ways of specifying default route (in -03), but this capability was removed. The original reason for having two ways of configuring the issue is well known to you as you suggested it in the first place. It was an attempt to solve your concerns about sent information being too big. As we modified prefix encoding to variable prefix field size option size is no longer a concern. Unfortunately, I missed one sentence that still suggest that. It will be removed in -05. Just be clear: sending only NEXT_HOP option without RT_PREFIX is not longer supported. Each NEXT_HOP MUST have at least one RT_PREFIX option. > Second, using default routes in the same option type of specific routes > means that they'd share the same faith - if specific routes are wrongly > configured in the same section of the config file, there is a risk that > the default route is wrongly configured too. Or, the default route is > something of last resort, so it would be better to have it configured in > a different place, communicated with a different ORO type. That argument is bogus. If your network administrator can't type ::/0, you should get a new admin. Some implementations may also accept word "default" in its configuration. > Third, if a single way of configuring default an specific routes with > DHCP then this means that a bigger software implementation would be > needed even for lightweight devices. Or, lightweight devices only use a > single route - the default route. My understanding is that all nodes that claim to be IPv6 compatible, must support ICMP Redirects, as defined in RFC4861. This implies required support for more than just a default route. > I suggest we separate the default route ORO from the specific routes ORO. You meant option, I assume. ORO (Option Request Option) is for requesting other options. Cheers, Tomek _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif -- ----------------------------------+--------------------------------- Reporter: alexandru.petrescu@… | Owner: Alexandru Petrescu Type: enhancement | Status: new Priority: trivial | Milestone: Component: dhcpv6-route-option | Version: Severity: In WG Last Call | Resolution: Keywords: | ----------------------------------+--------------------------------- Ticket URL: <http://trac.tools.ietf.org/wg/mif/trac/ticket/7#comment:5> mif <http://tools.ietf.org/mif/> _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
