Hi Syam,
Syam Madanapalli wrote: [cut]
Indeed it is similar.
When you have trusted routers with differing configurations, you have to make a decision what configuration to undertake.
For MTU, it's clear that you need to take the smallest (most restrictive) value advertised. This is because choice of a higher MTU is likely to have worse effects than
Yep, I agree. Using the smaller MTU one will be more safer. But it may be efficient to use the advertised MTU when the packet is destined for that particualr router because these two routers might have connected to different networks and the these routers may support different MTUs based on their hardware capabilities.
Certainly, but the packets may be lost if the router is misconfigured (which is a general statement...).
For DHC it's not the same choice, although it requires similar decision path. In DHC, any M or O flag set indicates that there is a DHC server available (albeit it may provide only limited function).
In this case, the host can use a DHC server if any of the trusted routers advertises this capability. In this case, the scenario is least restrictive, rather than most restrictive.
Certainly the routers should advertise consistent values, but the hosts should make reasonable decisions even if the routers disagree.
So you agree to maintain M/O flags per router basis and R1:M | R2:M|...|Rn:M = 1 means DHCPv6 Server available on the network? Similarly for O flag.
If you don't want to keep all the state for all routers, you could just listen to the router you have configured. If you believe its advertisements and it indicates O=1, then I guess that's sufficient to invoke Information-Request.
It's not necessary then to ask for other opinions, or track state on all routers (it's what C calls short-circuit evaluation).
If your host really desires to do DHC, and do not have an indication that it's available, some hosts will wish to do it anyway (Policy=1), but generally, you'd wish to see some indication that the service is available before resorting to it (especially for constrained hosts and links).
Greg
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
