Pekka Savola wrote:
On Tue, 4 Nov 2003, Erik Nordmark wrote:
There is really no reason to omit those prefixes that I could see. Rather than adding new code to verify this, shouldn't we just warn about
this situation and be done with it? Or even state that prefixes SHOULD
NOT (or MUST NOT) be omitted unless including them would cause a too big
packet (over MTU) to be sent?
Part of the consideration is the folks want to use RAs as frequent beacons for attachment detection. Making such beacons to carry potentially lots of prefixes, especially on bandwidth constrained (wireless) links, might be self-defeating.
Thus recommending that all prefixes be sent every 10 milliseconds (or whatever the min number is in the MIPv6 spec) might not be the best approach.
Uhh, this seems like a total abuse of the RA mechanism :-). The point of it to be able to carry the prefixes needed for autoconfiguration.
The final paragraph of Section 6.2.3 of rfc-2461 says that a router may want to omit options, but can't do so for a solicited RA. So the abuse isn't against the carrying of all prefixes.
The abuse of the RA mechanism is certainly there though (as abuse of wireless bandwidth). Everyone at the mobileIP session at IETF55 knew that it was a limited solution for some environments.
If it's supposed to be used for a beacon mechanism, I'd suggest
considering whether one could find a method that does not send prefixes at ALL (or, just send the prefix of the router with prefixlen=128 if you really insist).
This would enable you to retain the model where RA's would in fact be complete when they included prefix information options that the nodes would use.
There is a solution such as this which can omits all options in unsolicited RA, and still allows us to identify that we're on the same link or have moved. This is equivalent to Complete PIO information in RAs, but doesn't necessarily have the prefixes present in unsolicited RAs.
It's called Link Identifiers. Instead of (or as well as) sending PIOs, a link identifier option is sent by all routers on the same link.
This was described in Erik's MIPv6 hindsight document, but recent work by Monash and Samsung has aimed at making this LinkID Option small, and automatically configured.
It's available at:
http://www.ietf.org/internet-drafts/draft-pentland-mobileip-linkid-00.txt
This solution works if all routers on the link send LinkIDs, or if not all routers do, but transmit overlapping prefixes.
The completeness bit would work even if no other routers on the link support it though.
Of course, since section 6.2.3 recommends that routers advertise all options in solicited RAs, maybe the completeness bit could only be set in solicited RAs, if LinkID was present.
There are some other things regarding RA contents (there's no solicitation indication) which would be nice, but I guess that's not what we're talking about here.
So we have at least two solutions which provide unambiguous prefix indications:
LinkID + Solicited RA (lower overhead) Completeness Bit (simpler)
Whether these are aimed at RFC-2461bis or receive attention in IPv6 or DNA is another matter.
Greg
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
