7. Border Router Behavior
A 6LBR handles the sending of RAs and processing of NSs from hosts as specified above in Section 6. A 6LBR SHOULD always include an ABRO in the RAs it sends, listing itself as the 6LBR address. This requires that the 6LBR maintain the version number in stable storage and increase the version number when some information in its RAs changes. The information whose change affects the version is in the PIOs (the prefixes or their lifetimes) and in the 6CO (the prefixes, CIDs, or lifetimes).
In addition, a 6LBR is somehow configured with the prefix or prefixes that are assigned to the LoWPAN and advertises those in RAs as in [RFC4861]. In the case of route-over, those prefixes can be disseminated to all the 6LRs using the technique discussed in Section 8.1. However, there might be mechanisms outside of the scope of this document that can be used as a substitute for prefix dissemination in the route-over topology (see Section 1.4).
If the 6LoWPAN uses header compression [RFC6282] with context, then the 6LBR needs to manage the CIDs and advertise those in RAs by including 6COs in its RAs so that directly attached hosts are informed about the CIDs. Below, we specify things to consider when the 6LBR needs to add, remove, or change the context information. In the case of route-over, the context information is disseminated to all the 6LRs using the technique discussed in Section 8, unless a different specification provides a substitute for this multihop distribution.
7.1. Prefix Determination
The prefix or prefixes used in a LoWPAN can be manually configured or can be acquired using DHCPv6 Prefix Delegation [RFC3633]. For a LoWPAN that is isolated from the network either permanently or occasionally, the 6LBR can assign a ULA prefix using [RFC4193]. The ULA prefix should be stored in stable storage so that the same prefix is used after a failure of the 6LBR. If the LoWPAN has multiple 6LBRs, then they should be configured with the same set of prefixes. The set of prefixes is included in the RA messages as specified in [RFC4861].
7.2. Context Configuration and Management
If the 6LoWPAN uses header compression [RFC6282] with context, then the 6LBR must be configured with context information and related CIDs. If the LoWPAN has multiple 6LBRs, then they MUST be configured with the same context information and CIDs. As noted in [RFC6282], maintaining consistency of context information is crucial for ensuring that packets will be decompressed correctly.
The context information carried in RA messages originates at 6LBRs and must be disseminated to all the routers and hosts within the LoWPAN. RAs include one 6CO for each context.
For the dissemination of context information using the 6CO, a strict life cycle SHOULD be used in order to ensure that the context information stays synchronized throughout the LoWPAN. New context information SHOULD be introduced into the LoWPAN with C=0, to ensure that it is known by all nodes that may have to perform header decompression based on this context information. Only when it is reasonable to assume that this information was successfully disseminated SHOULD an option with C=1 be sent, enabling the actual use of the context information for compression.
Conversely, to avoid the situation where nodes send packets that make use of previous values of contexts -- which would result in ambiguity when receiving a packet that uses a recently changed context -- old values of a context SHOULD be taken out of use for a while before new values are assigned to this specific context. That is, in preparation for a change of context information, its dissemination SHOULD continue for at least MIN_CONTEXT_CHANGE_DELAY with C=0. Only when it is reasonable to assume that the fact that the context is now invalid was successfully disseminated should the CID be taken out of dissemination or reused with a different Context Prefix field. In the latter case, dissemination of the new value again SHOULD start with C=0, as above.