NEMO Basic Support update IETF 61

Status IANA assignments done Very close to AUTH48 call Some issues raised recently We need to figure out if we want to make these changes now (potential delay) or do it later in a –bis draft

Proposed changes since IESG approval All changes discussed on the WG mailing list Changes classified as Critical changes If this change is not made, the protocol will not function, will create an unacceptable security problem, or will be problematic for the Internet. Critical changes require document recycled through the WG last call, IETF last call, etc. Important changes If this change is not made, interoperability might be affected WG consensus required for the changes, IESG needs to be made aware of the changes, done during AUTH48 Desirable changes This change would clarify a point, make sections of the document consistent, or would ease implementation decisions. Options –Do it later in a –bis document –Treat them just as important changes WG chairs recommend they be done later in a –bis document Minor changes Done during AUTH48, AD approval required

Critical Issues None

Important Changes Issue 42 ( ) Is it okay for the MR to exclude prefixes in binding update sent to update existing binding cache entries? Has the MR switched to using implicit mode? How does the MR stop using certain prefixes and continue using other prefixes while still maintaining the binding cache entry? Resolution MR includes all prefixes in every binding update (even the ones which refresh an existing binding cache entry) Home Agent behavior –If a refresh BU contains a prefix that is not in existing BCE, setup forwarding for the prefix –If a refresh BU does not contain a prefix that is in existing BCE, stop forwarding for the prefix

Important Changes (contd.) Binding Ack status values MR discards BAck with status values 141 and 142 in implicit mode 141 Invalid Prefix 142 Not Authorized for Prefix MR discards Back with status value 143 in explicit mode 143 Forwarding Setup failed (prefixes missing) Most probably due to mis-configuration Silent discard is not good for user experience MR pretends nothing is happening Proposal Treat them as fatal errors Could generate an error on the user interface No change on the wire

Important Changes (contd.) The use of tunnel encapsulation limit It was specified wrong in the document Tunnel encapsulation limit cannot be used by the MR to limit the number of nested MRs Resolution Remove the paragraph Issue 39 ( ) Conflicting requirements for setting lifetime in router advertisements sent by mobile routers on the egress interface SHOULD and MUST used Resolution Change to SHOULD everywhere

Important Changes (contd.) Add the following text to the security considerations section If the Mobile Router sends a Binding Update with a one or more Mobile Network Prefix options, the Home Agent MUST be able to verify that the Mobile Router is authorized for the prefixes before setting up forwarding for the prefixes. Binding Ack status 143 “Forward Setup failed” doesn’t say why it failed (explained in text but not obvious by just looking at the string associated with the status value) Proposal Change to “Forwarding Setup failed (missing prefixes)” Any other change would require IANA updating their registries

Important Changes (contd.) Sending routing updates on the visited link Earlier text When the mobile router moves and attaches to a visited network, it MUST stop sending routing updates on the interface with which it attaches to the visited link. Cant be enforced by the visited link Wrong use of the MUST keyword New text When the Mobile Router moves and attaches to a visited network, it should stop sending routing updates on the interface with which it attaches to the visited link. They will be dropped by the visited link if authentication of routing protocol messages is enabled on the visited link

Other changes Desirable changes Changes to improve readability (and clarity) Please see Minor changes Please see

Conclusions There are no critical changes that indicate protocol is broken A few changes are needed to make sure interoperability is achieved There are some changes that improve the text Authors’ recommendation The proposed changes don’t require recycling the document to the WG IESG members should be made aware of the changes Do the changes during AUTH48