[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt
Hi Vijay,
Thanks for all the comments. Please see responses inline.
Sorry for the late reply.
Regards,
Ahmad
> -----Original Message-----
> From: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org] On
> Behalf Of Vijay Devarapalli
> Sent: Friday, March 06, 2009 7:21 PM
> To: draft-ietf-mext-binding-revocation at tools.ietf.org
> Cc: Julien Laganier; mext
> Subject: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt
>
> Hello,
>
> I reviewed this document. It needs some work before it can be
> sent to the IESG. Comments follow.
[Ahmad]
Okay, no problem, these comments improve readability of the draft.
we will go over them and all others and address them before it is sent
to IESG.
>
> > Abstract
> >
> > This document defines the revocation semantics for terminating a
> > mobile node's mobility session and associated resources.
>
> How about saying
>
> This document defines a binding revocation mechanism to terminate a
> mobile node's mobility session and release the associated
> resources.
[Ahmad]
Looks good. Thx.
>
> > In the case of Mobile IPv6 and for administrative
> reason, sometimes
> > it becomes necessary to inform the mobile node that its
> registration
> > has been revoked and the mobile node is no longer able
> to receive IP
> > mobility service using its Home Address. In some networks where
> > Mobile IPv4 [RFC3344] has been deployed, a similar Mobile IPv4
> > registration revocation mechanism has been specified [RFC3543].
>
> The MIPv4 registration mechanism was specified in the IETF,
> not in the networks where Mobile IPv4 has been deployed. :) I
> think the last sentence needs to be re-worded.
[Ahmad]
What about the following:
In the case of Mobile IPv6 and for administrative reason, sometimes
it becomes necessary to inform the mobile node that its registration
has been revoked and the mobile node is no longer able to receive IP
mobility service using its Home Address. A similar Mobile IPv4
registration revocation mechanism [RFC3543] has been specified by
IETF for providing a revocation mechanism for sessions that were
established using Mobile IPv4 registration [RFC3344].
>
> > This document defines the semantics of the revocation
> mechanism of a
> > mobile node registration binding, which could have been
> established
> > using a Client Mobile IPv6 or any of its extensions, e.g. Proxy
> > Mobile IPv6 signaling.
>
> Re-write as
>
> This document specifies the binding revocation mechanism to remove
> a mobile node's mobility sessions. The same mechanism can
> be used to
> revoke bindings created using both Mobile IPv6 [RFC 3775] and Proxy
> Mobile IPv6 [RFC 5213].
>
> We don't use "Client Mobile IPv6" in the IETF. :) And we need
> references to RFC 3775 and 5213, since they are mentioned
> here for the first time in this document.
[Ahmad]
What about the following text:
This document specifies a binding revocation mechanism that can be
used to revoke a mobile node's mobility session(s). The same
mechanism can be used to revoke bindings created using Mobile IPv6
[RFC3775] or any of its extensions, e.g. Proxy Mobile IPv6
[RFC5213].
>
> > 2.2. Terminology
> >
> > All the general mobility related terminology and
> abbreviations are to
> > be interpreted as defined in Mobile IPv6 specification
> [RFC3775] and
> > Proxy Mobile IPv6 specification [RFC5213].
>
> Maybe you should define the term "mobility agent" here.
> Basically, it would be the Home Agent, LMA and the MAG. You
> have used "mobility node"
> throughout the document. A "mobility node" is kind if vague.
> Suggest replacing all occurrences with "mobility agent".
[Ahmad]
Good idea.
I will replace the mobility node by mobility agent where it is
applicable. However, I do not see the need for having another definition
for the mobility agent term.
>
> > In the case of Client Mobile IPv6, the revocation
> procedure can be
> > initiated by the home agent.
>
> "can be"? It is always the home agent right? Suggest re-wording to
>
> In the case of Mobile IPv6, the revocation procedure is
> initiated by
> the home agent.
[Ahmad]
Okay, please see the comment below.
>
>
> If the home network decides to
> > terminate the service of the mobile node, the home agent sends a
> > Binding Revocation Indication (BRI) message to the
> mobile node. The
> > home agent includes the HoA in the type 2 routing header
> as specified
> > in [RFC3775] to indicate the impacted mobile node
> binding. When the
> > mobile node receives a BRI message with its HoA included and the
> > Acknowledge (A) bit is set, the mobile node responds by sending a
> > Binding Revocation Acknowledgement (BRA) message.
>
> hmm... Won't the mobile node delete the binding first before
> sending the BRA message?
[Ahmad]
It could, but this is implementation specific. Some implementation may
send BRA at the same time it starts the process of eliminating the
session binding or even before. IMO, We should not specify a specific
sequence of events. But, what about rewording the whole paragraph as
follows:
In the case of Mobile IPv6, if the home network decides to terminate
the service of the mobile node, the home agent sends a Binding
Revocation Indication (BRI) message to the mobile node. The home
agent includes the HoA in the type 2 routing header as specified in
[RFC3775] to indicate the impacted mobile node binding. When the
mobile node receives a BRI message with its HoA included and the
Acknowledge (A) bit is set, the mobile node responds by sending a
Binding Revocation Acknowledgement (BRA) message.
>
> > In the case of DSMIPv6 [ID-DSMIP6], the revocation
> procedure can also
> > be initiated by the home agent.
>
> Again, it is always the home agent that initiates the
> revocation mechanism. Who else can do it in DS-MIPv6?
[Ahmad]
Will fix it as above.
>
> If the home network decides to
> > terminate the service of the mobile node, the home agent
> sends a BRI
> > message to the mobile node to indicate the termination
> of the mobile
> > node IP Mobility service. The home agent may include the HoA
> > option
>
> s/HoA option/IPv4 Home Address Option/
>
> I don't know of any other option that carry the IPv4 home address.
[Ahmad]
Sure. Done.
>
> > with the mobile node assigned home IPv4 address. After
> receiving the
> > BRI message with the Acknowledge (A) bit is set, the mobile node
> > responds by sending a BRA message.
>
> Again, the mobile node would delete the binding first, I guess.
[Ahmad]
Similar to the response above.
>
> > 3.2. Client MIPv6 and DSMIP6 Use Case
>
> s/Client MIPv6/Mobile IPv6/
>
[Ahmad]
Sure, will take it as a global comment.
> >
> > Binding revocation mechanism is applicable to Client
> Mobile IPv6 and
> > DSMIPv6 session(s) when the home agent needs to inform the mobile
> > node that its binding registration has been revoked, e.g. for an
> > administrative reason. This mechanism enables the home domain to
> > dynamically allow the user to act upon the revocation message in
> > order to recover its interrupted mobile IPv6 services.
>
> What does the last sentence mean? Isn't the mobile node
> required to do something when it gets a revocation message?
> The mobile node has to find another home agent, right? How
> can its services not be interrupted?
[Ahmad]
Hmmm.. I guess that what the sentence says. "to recover from its
interrupted mobile IPv6 services"
So, I guess we are on the same page.
>
> > In this case, the home agent sends a BRI message to
> indicate to the
> > mobile node that its current mobile IPv6 binding has
> been revoked and
> > it no longer can receive IP mobility service. The home agent
> > includes the mobile node home address in Type 2 routing header as
> > used in [RFC3775] and sets the Revocation Trigger field
> to a proper
> > value, e.g. Administrative Reason. In the case of
> DSMIPv6 session,
> > the home agent may additionally include the mobile node
> assigned IPv4
> > Home Address in the IPv4 Home Address Option. When the
> mobile node
> > receives the BRI message, it sends a BRA message as described in
> > Section 11.2 to the home agent. Figure 1 illustrates the message
> > sequencing when home agent revokes a mobile node binding
> > registration.
> >
> >
> > MN HA
> > | |
> > | HoA in Type 2 Hdr + BRI [seq.#, A bit] |
> > |<------------------------------------------|
> > | |
> > | |
> > | |
> > | HoA in Destination Option BRA[seq.#] |
> > |------------------------------------------>|
> > | |
> > | |
>
> Why is the HoA required in a destination option? The BRA
> message can just be sent from the CoA with no home address
> option in it. The Home Agent just needs to match the BRA to
> the BRI message using the sequence number field.
[Ahmad]
This was based a good discussion and comment from Christian back in
Sept. 2008 on rev 00. Since the BRI and the BRA use the same IPsec SA
that is used for the BU/BA, then we need to follow the same mechanism
when sending BRI and BRA.
>
> BTW, in figure 2, there is no HoA destination option in the
> BRA message.
[Ahmad]
Will fix it accordingly.
>
> > 3.3.1. Termination of Multiple Care-of Addresses Bindings
> >
> > In the case of multiple care-of addresses, the home
> agent maintains
> > different binding for each pair of care-of address and
> home address.
> > These bindings are also indexed and identified during
> the mobile node
> > registration using a Binding ID mobility option
> [ID-MCoA]. In this
> > case, the HA may revoke any binding, more than one
> binding, or all of
> > the bindings for the same mobile node home address.
>
> Re-phrase the last sentence as
>
> In this case, the HA may revoke one or more bindings for the same
> mobile node home address.
[Ahmad]
Thx. Done.
>
> > In the case when home agent revokes a single binding for a mobile
>
> s/In the case when/In case/
[Ahmad]
Ok.
>
> > node with multiple care-of addresses registration, the home agent
> > sends a BRI message to the mobile node with the corresponding BID
> > option included and the HoA is in the Type 2 routing header.
>
> Rephrase as
>
> node with multiple care-of addresses registration, the home agent
> sends a BRI message to the mobile node with the corresponding BID
> option included.
[Ahmad]
Is the idea NOT to mention the inclusion of HoA in Type 2 header as it
is understood or there is another reason.
>
> > If the
> > home agent needs to revoke more than one of the mobile node
> > registered care-of addresses, the home agent includes all the
> > corresponding Binding ID options which reference these care-of
> > addresses in the same BRI message.
>
> Rephrase as
>
> If the
> home agent needs to revoke more than one of the mobile node
> registered care-of addresses, the home agent includes all the
> corresponding Binding ID options in the same BRI message.
>
[Ahmad]
Ok.
>
> > 3.4. Proxy MIPv6 Use Case
> >
> > Since the Mobile node does not participate in the
> mobility mechanism
> > in the case of PMIPv6, there are many scenarios where Binding
> > Revocation mechanism is needed to clean resources and
> make sure that
> > the mobility entities, e.g. MAG and LMA, are always synchronized
> > with respect to the status of the existing proxy mobile IPv6
> > bindings. The binding revocation mechanism is generic
> enough that
> > can be used in all applicable PMIPv6 scenarios and deployment
> > options. For example, this revocation mechanism is
> still applicable
> > and can be used when PMIPv6 is deployed with IPv6 or
> IPv4 transports
> > and when the mobile node uses IPv4 or IPv6 address as
> specified in
> > [ID-PMIP6-IPv4].
>
> Thats a tall claim. We don't really where all PMIPv6 might be used.
> Suggest replacing the last two sentences with the following.
>
> The binding revocation mechanism is generic enough that can be
> used for all scenarios described in RFC 5213 and [ID-PMIP6-IPv4].
[Ahmad]
Sure, what about the following:
"
............ The binding revocation mechanism is generic enough that
can be used for all Proxy Mobile IPv6 scenarios that follow [RFC5213]
and [ID-PMIP6-IPv4] specifications.
"
>
> > 3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding
> >
> > The local mobility anchor may send a BRI message to the
> mobile access
> > gateway, hosting a specific proxy mobile IPv6 binding, with the
> > appropriate value in the revocation trigger field to
> indicate that
> > the mobile node binding has been terminated and the MAG
> can clean up
> > the applicable resources. When the MAG receives a BRI
> message, the
> > MAG identify the respected binding and if the (A) bit was set in
> > the
>
> s/identify/identifies/
[Ahmad]
Ok.
>
> > The process identified above can also be used by the LMA
> in scenarios
> > other than the inter-MAG handoff with the proper
> revocation trigger
> > value to indicate to the peer MAG that a specific proxy
> mobile IPv6
> > binding or bindings have been revoked.
> >
> >
> > sMAG tMAG LMA
>
> Can we call this oldMAG and newMAG? We have traditionally
> used these terms in the IETF.
[Ahmad]
No problem. Fixed.
>
> > 4. Security Model
> >
> > The binding revocation protocol described here uses the
> same security
> > association between the MN and the HA or the MAG and the
> LMA that has
> > been used to exchange the corresponding Client MIPv6 or
> Proxy MIPv6
> > BU and BA when the mobile node binding was created. If IPsec is
> > used, the traffic selectors associated with the SP protecting BU
> > and
>
> s/SP/SPD entry/
>
> There are few places where this needs to be replaced.
>
[Ahmad]
Thx. Done.
> > BA MUST be extended to include Binding Revocation
> Signaling MH type
> > <IANA-TBD>. Extending the traffic selectors of the SP
> in order to
> > reuse the SA protecting BU and BA (instead of creating new ones)
> > ensures that those SA will be up and running when the
> revoking entity
> > needs to send a Binding Revocation Signaling message.
> >
> > Additionally, in the case when the LMA receives a BRI
> which indicates
> > a bulk termination, i.e., the (G) bit is set, the LMA MUST verify
> > that the MAG sending the binding revocation indication message is
> > authorized to invoke Global revocation.
>
> Why require this? It is after all the MAG that created all
> these bindings. And now the MAG wants to delete the bindings
> it created at the LMA. So why does this alone require an
> additional authorization step?
[Ahmad]
Actually, the intention was for the case when the (G) bit set and the R.
T. is set to "Per-Peer policy", which means all binding between the MAG
and the LMA to be deleted. Additionally, I see your point, but something
could have happened to the MAG between the time it created all of these
session and time of terminating them. Even in the case of creating a
single binding, RFC5213 left the door open for the LMA to make sure that
the MAG is authorized for sending the PBU on behalf of the mobile node.
This case is much more severe and impact all bindings and I believe it
worth having this validation.
>
> > 5. Exchanging Binding Revocation Messages over an IPv4 Transport
> > Network
> >
> > In some deployments, the network between the MAG and the
> LMA may only
> > support IPv4 transport. In this case, the Binding Revocation
> > messages (BRI and BRA) are tunneled over IPv4. If the
> Proxy Binding
> > Update and Proxy Binding Acknowledgment messages are
> sent using UDP
> > encapsulation to traverse NATs, then the Binding
> Revocation messages
> > are sent using the same UDP encapsulation. The same UDP
> port that
> > was used for the Proxy Binding Update and Proxy Binding
> > Acknowledgement messages will also be used when transporting
> > Binding
>
> Is the destination port in the BRI set to the DS-MIPv6 port
> or the source UDP port seen on the PBU from the MAG to the
> LMA? The NAT on the path might have changed the source UDP
> port on the PBU. So do you want the BRI to be sent to that port?
[Ahmad]
BRI should use the source port of the PBU which is saved in the BCE.
>
> > The following options are valid in a Binding Revocation
> Indication:
> >
> > o Home Network Prefix option [RFC5213]. This option MAY be used
> > when the (P) bit is set. This option MUST be present
> when the BRI
> > is used to revoke a single PMIP binding cache entry.
> >
> > o Mobile Node Identifier Option [RFC4283]. This option
> is mandatory
> > when the (P) bit is set. Additionally, If the (G)
> bit is set by
> > the mobile access gateway, this option carries the
> MAG identity.
> >
> > o Binding ID mobility option [ID-MCoA]. This option is
> mandatory if
> > the sending mobility entity request to terminate one
> binding of a
> > multi care-of addresses bindings for the same mobile
> node. The
> > sending mobility entity may include more than one of
> the Binding
> > ID mobility options.
> >
> > o IPv4 Home Address option which contains the mobile
> node home IPv4
> > address [ID-DSMIP6]. This option is included only
> when the IPv4
> > HoA Binding only (V) bit is set.
> >
> > o Alternate Care-of Address mobility option [RFC3775].
> This option
> > MAY be included to indicate the Care-of Address of the mobile
> > node's binding that is being revoked. In the case
> when the Global
> > (G) bit set, this option identifies all the mobility
> bindings that
> > share the same care-of address. Additionally, if the
> Global (G)
> > bit set, more than one Alternate Care-of Address
> mobility options
> > MAY be present in the BRI message.
>
> I don't understand the last one. Why is this needed? If
> Mobile IPv6 is used, the home address would identify the
> right binding that needs to be deleted. If MCoA is used, then
> the BID would identify the right binding.
> If PMIPv6 is used, the home network prefix option, MN ID
> option and the
> IPv4 home address options are sufficient to identify the
> right binding.
> So what is the last one used for?
[Ahmad]
This was discussed during the wg LC. The point here is the following:
In case the Global revocation, currently the LMA does not, for example,
keep track of the MAG ID or any parameter which is shared among all of
these bindings. However, if the Care-of-Address is included, then the
LMA will revoke all of the bindings that share this Care-of-Address. If
the MAG uses more than one pCoA for the mobility sessions that reside on
the LMA, the MAG needs to include each pCoA in a separate Alternate
Care-of Address option.
>
> > 7.1. Sending Binding Revocation Messages
> >
> > When sending a Binding Revocation message, the sending
> mobility node,
> > initiator, follows the rules of constructing a Mobility
> Header as in
> > Section 9.2 of [RFC3775] with the exception of setting
> the MH Type
> > field to <IANA-TBD and the appropriate value of the Binding
> > Revocation Type field.
>
> Section 9.2 of RFC 3775 talks about processing Mobility
> Headers. Perhaps you meant some other section from RFC 3775.
[Ahmad]
What about the following updated text:
When sending a Binding Revocation message, the sending mobility node,
initiator, constructs the packet as it would any other Mobility
Header
with the exception of setting the MH Type field to <IANA-TBD>.
>
> > The mobility entity which initiates the revocation process,
> > initiator, MUST use the underlying IPsec security
> association that
>
> You have already introduced the term "initiator" to refer to
> the "sending mobility node" in the first paragraph. It is
> repeated here.
[Ahmad]
sure; removed.
>
> > When a mobility entity initiate the binding revocation process by
> > sending a Binding Revocation Indication message, the
> initiator MUST
> > construct the BRI message as described in Section 6.1.
> In the BRI
> > message, the initiator MUST set the Sequence Number
> field to the next
> > sequence number available for Binding Revocation.
>
> Why? It can be any random number, right? It is only used for
> matching BRA messages to BRI messages. You don't normally
> sending a sequence of BRI messages to a mobile node right?
> Not like sending binding updates with increasing sequence numbers.
>
[Ahmad]
That what the "next sequence number" means.
We did not say that this sequence number is monotonic, for example.
> > On the other hand, when the responder acknowledge the
> BRI message
> > by
>
> "On the other hand" of what? Just say "When the responder..."
>
[Ahmad]
Okay :) replaced by However, ....
>
> > 7.2. Receiving Binding Revocation Messages
> >
> > When receiving a Binding Revocation message, the
> receiving mobility
> > node MUST verify the Mobility Header as in [RFC3775].
>
> I think here you should mention section 9.2 of RFC 3775.
[Ahmad]
Ok.
>
> > If the packet
> > is dropped due to failing any of the Mobility Headers
> test check, the
> > receiving node MUST follow the processing rules as in
> Section 9.2 of
> > [RFC3775]. For example, it MUST send a Binding Error
> message with
> > the Status field set to 2 (unrecognized MH Type value)
> if it does not
> > support the received binding revocation message type.
>
> The "MUST" here does not make sense. Re-word the last sentence to,
>
> If the receiving node does not support the Binding Revocation
> Indication message and does not recognize the new MH type, it sends
> a Binding Error message with the Status field set to 2, as
> described
> in [RFC3775].
[Ahmad]
Ok.
>
> > Since some mobility entities, e.g. LMA and MAG, are allowed to
> > receive and possibly send a BRI or a BRA for different
> cases, IPsec
> > mechanism will prevent any possible man in the middle reflection
> > attack.
>
> Not sure what this means. What is IPsec is not used? You have
> indicated in a number of places in the document that there
> could be other mechanisms.
[Ahmad]
What this means is: If IPsec is used, then there is no room for
reflection attack.
Text modified as follows:
"
Since some mobility entities, e.g. LMA and MAG, are allowed to
receive and possibly send a BRI or a BRA for different cases,
therefore, if IPsec is used to secure signaling between the MAG and
the LMA, it prevents any possible man in the middle reflection
attack.
"
>
> > Upon receiving a packet carrying a Binding Revocation
> Indication, the
> > receiving mobility entity, responder, validates that the
> packet was
> > received protected with the underlying IPsec protection with the
> > responding mobility entity.
>
> Here we are mandating IPsec protection for the BRI message.
> Is this the intention? If yes, a few other places need to be fixed.
[Ahmad]
I do not think Binding Revocation should mandate more protection than
what is already mandated in PMIPv6 or MIPv6. So I guess we can rephrase
the above as follows:
Upon receiving a packet carrying a Binding Revocation Indication, the
receiving mobility entity, responder, validates that the packet was
received protected with the security association that already has
been established with the responding mobility entity and used during
the registration signaling phase, e.g., IPsec SA.
Actually there is another instance under sending section which I also
fixed similarly, as follows:
The mobility entity which initiates the revocation process MUST use
the underlying security association that has been used during the
mobile node binding registration to secure the BRI and BRA messages
transmission with the responding mobility entity, e.g., IPsec SA.
>
> > Upon receiving a packet carrying a Binding Revocation
> > Acknowledgement, the receiving mobility entity, initiator, MUST
> > validate that Sequence Number field matches the Sequence
> Number of an
> > outstanding Binding Revocation Indication that was sent by the
> > initiator. If the Sequence Number does not match any
> sequence number
> > of any of the outstanding BRI, the receiving node MUST ignore the
> > message but MAY log the event.
>
> s/ignore/silently drop/
[Ahmad]
Sure, will use silently discard.
>
> > 7.3. Retransmission of Binding Revocation Indication
> >
> > If the sending mobility entity does not receive a
> Binding Revocation
> > Acknowledgement in response to the outstanding Binding Revocation
> > Indication before the MINDelayBRIs timer expires, the mobility
> > entity, e.g. LMA, may retransmit the same BRI message up to the
> > BRIMaxRetriesNumber as defined in Section 12. If the revoking
> > mobility entity does not receive a BRA message after the maximum
> > number of retransmits have been sent, the revoking
> mobility entity
> > can clean the mobile node binding cache and all
> resources associated
> > with this binding. The revoking mobility entity may log
> the event.
>
> Is it a simple re-transmit scheme or do we have to
> exponentially backoff for subsequent BRI messages?
[Ahmad]
It should be a simple re-transmit scheme.
I guess it does not have the characteristics of BU/BA as it does not
happen that frequent.
>
> > In a race condition case, the home agent may receive a
> BU from the
> > mobile node while the mobile node's BCE has the revocation in
> > progress flag set, the home agent should handle this
> case based on
> > the reason for sending the Binding Revocation Indication
> message and
> > its local policy. In this case, if the home agent
> accepts the BU, it
> > needs to update the mobile node BCE accordingly, e.g.
> removing the
> > revocation in progress flag.
>
> Why is this needed? Shouldn't the home agent just reject the
> BU based on the fact that it in the process of revoking the
> binding? Why should this
> be subject to "a local policy"? If you do want to multiple
> options here, you have to recommend a default one.
[Ahmad]
I guess this text was added to address the case when the HA sends a BRI
message to the MN when the mobile node just made a handoff and sent a BU
with a new care-of address. IMO, the HA handling should be based on the
reason for sending the BRI. However, if we allow the HA to reject the
BU, which Status Code should we use?
>
> > In a race condition case, the local mobility anchor may
> receive a PBU
> > from the mobile access gateway while the mobile node's
> proxy BCE has
> > the revocation in progress flag set, the LMA should
> handle this case
> > based on the reason for sending the Binding Revocation Indication
> > message and its local policy. In this case, if the LMA
> accepts the
> > PBU, it needs to update the mobile node proxy BCE
> accordingly, e.g.
> > removing the revocation in progress flag.
>
> Same as before. I think the LMA should just reject the PBU.
[Ahmad]
See the above comment?
>
> I didn't review much of the text in sections 9.1, 9.2, 10.1,
> 10.2, 11.1 and 11.2. These sections have too much repetitive text
[Ahmad]
Thx. for all the comments.
If you have any specific ones on these sections, please let us know so
we can address them.
>
> > 13. IANA Considerations
> >
> > This document defines two new messages BRI and BRA, as
> described in
> > Section 6.1 and Section 6.2 by using Binding Revocation
> types of 1
> > and 2 of the Binding Revocation Message which is defined in in
> > Section 6 and uses a MH type <IANA-TBD>. The new Mobility Header
> > type value needs to be assigned from the same numbering space as
> > allocated for the other Mobility Header types.
>
> This section is not complete. Needs a re-write.
[Ahmad]
OK.
Please see a re-write for the whole section below.
>
> We define one new mobility header message - the binding
> revocation message.
>
> Then we need to create a new namespace for the "Binding
> Revocation Type"
> field with the current assignments.
>
> 0 Reserved
> 1 Binding Revocation Indication Message
> 2 Binding Revocation Acknowledgement Message
> All other values are reserved
[Ahmad]
I do not think we need to reserve a name space for this.
In case that is needed in the future, we can do that then.
>
> Then we need to create another namespace for the "Revocation
> Trigger" in the Binding Revocation Message. I think IANA
> should manage this field too.
>
> Then we need yet another namespace for the "Status" field in
> the BRA message. I think this should also be managed by IANA.
>
> So you need to request all of these from the IANA.
{Ahmad]
What about the following updated IANA section?
"
13. IANA Considerations
This document defines a new Binding Revocation Message using a new
Mobility Header Type <IANA-TBD>, as described in Section 6. The new
Mobility Header type value needs to be assigned from the same
numbering space as allocated for the other Mobility Header types.
In addition, this document also creates a new namespace for the
Binding Revocation Trigger Field defined in Binding Revocation
Indication message as described in Section 6.1, and are the
following:
0 Reserved
1 Unspecified
2 Administrative Reason
3 Inter-MAG Handoff - same Access Types
4 Inter-MAG Handoff - different Access Types
5 Inter-MAG - Unknown Handoff
6 Per-Peer Policy
7 Revoking Node Local Policy
8 User Initiated Session(s) Termination
9 Access Network Session(s) Termination
10 IPv4 HoA Lease Expires
11 Possible Out-of Sync BCE State
250-255 Reserved For Testing Purposes only
All other values are Reserved
Future values of the Option Type can be allocated using Standards
Action or IESG Approval [RFC2434].
Furthermore, this document creates a third new name space "Status
Code" for the Status field in the Binding Revocation Acknowledgement
message. The current values are described in Section 6.2, and are
the following:
0 success
1 partial success
128 Binding Does NOT Exist
129 IPv4 HoA Binding Does NOT Exist
130 IPv4 Home Address Option Required
131 Global Revocation NOT Authorized
132 CAN NOT Identify Binding
133 Revocation Failed, MN is Attached
Future values of the Status field can be allocated using Standards
Action or IESG Approval [RFC2434].
All fields labeled "Reserved" are only to be assigned through
Standards Action or IESG Approval.
"
>
> Hope this helps.
[Ahmad]
Of course. thanks!
>
> Vijay
> _______________________________________________
> MEXT mailing list
> MEXT at ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>