Subject: [nemo] RE: Text changes to close issue 10

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 7 Aug 2003 11:11:45 +0100

I Vijay:

I favor these changes too. Thanks for all the work.

There's still the original question of differentiating implicit and IGP?

Also, MUST is a bit severe for the 143, ain't it?

Pascal

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: mercredi 6 août 2003 20:01
> To: [email-masked]
> Cc: Pascal Thubert (pthubert)
> Subject: Text changes to close issue 10
> 
> hi all,
> 
> I made some significant changes to the text. this is for closing
> issue 10. I realised that the Prefix Table and implict mode has
> been a source for lot of confusion. many people dont seem to
> like what was intended to be a simple solution. anyway here is
> what I propose we should do.
> 
> 1. use Prefix Table only for verification in explicit mode. it
> is used only if the HA needs to be prevent misbehaving MRs from
> claiming prefixes that belong to other MRs. if a particular
> deployment is such that the HA does not expect MRs to misbehave
> then the Prefix Table is not required.
> 
> 2. make it clear in Implicit mode that any mechanism can be used.
> it is totally internal to the Home Agent. remove all refereces to
> using Prefix Table in implicit mode.
> 
> 3. change Binding Ack status 143 to 'Forwarding Setup failed'. it
> is used to indicate that the HA was unable to setup forwarding
> for the Mobile Network when it received a Binding Update from the
> MR in implicit mode.
> 
> and here the proposed text changes to reflect this. let me
> know what you think about these changes.
> 
> 
> replace
> >       Prefix Table
> >
> >               It is a list of a mobile network prefixes indexed
> >               by the extended Home Address of a Mobile Router.  The
> >               prefix table is managed by the Home Agent.  When a Home
> >               Agent receives a Binding Update without any options,
> >               it searches a correspondent Mobile Network Prefix in
> >               the prefix table, keying with the Home Address of the
> >               requesting Mobile Router.  This is an optional data
> >               structure.
> 
> with
>       Prefix Table
> 
>               It is a list of a mobile network prefixes indexed
>               by the extended Home Address of a Mobile Router.  The
>               prefix table is managed by the Home Agent.  This is an
>               optional data structure.
> 
> replace
> >       143     Mobile Network Prefix information unavailable.
> 
> with
>         143     Forwarding Setup failed
> 
> 
> replace
> >          The Home Agent can use any mechanism (not defined
> >          in this document) to determine the Mobile Network Prefix(es)
> >          owned by the Mobile Router.  One of the possible mechanisms is
> >          where the Home Agent maintains a pre-configured Prefix Table
> >          listing all the Mobile Network prefixes owned by a particular
> >          Mobile Router.  This table is keyed on the Home Address of the
> >          Mobile Router.
> 
> with
> 
>          The Home Agent can use any mechanism (not defined
>          in this document) to determine the Mobile Network Prefix(es)
>          owned by the Mobile Router and setup forwarding for the Mobile
>          Network.  One example would be manual configuration at the
>          Home Agent mapping the Mobile Router's home address to the
>          information required for setting up forwarding for the Mobile
>          Network.
> 
> replace
> >    In some scenarios, the Home Agent might need to maintain a Prefix
> >    Table of Mobile Routers and the IPv6 prefixes owned by Mobile
> >    Routers.  The Home Agent MUST maintain this table if the Mobile
> >    Routers operate under the implicit mode where they do not include any
> >    prefix information in the Binding Updates.
> >
> >    Each entry in the Prefix Table conceptually contains the following
> >    fields:
> >
> >     -  The Home Address of the Mobile Router.  This field is used as the
> >        key for searching the pre-configured prefix table.
> >
> >     -  The Mobile Network Prefix of the Mobile Router associated with
> >        the Home Address.
> >
> >    In some deployment scenarios, it is necessary for Home Agent to
> >    prevent a misbehaving Mobile Router from claiming mobile network
> >    prefixes belonging to another Mobile Router.  The Home Agent can
> >    prevent such attacks if it maintains the Prefix Table and verifies
> >    the Prefix Information provided by the Mobile Router against the
> >    if the Binding Update contained explicit prefix information in the
> >    form of either the Mobile Network Prefix Option or the Mobile Network
> >    Prefix Length Option.
> 
> with
> 
>    In some deployment scenarios it may be necessary for the Home Agent
>    to prevent a misbehaving Mobile Router from claiming mobile network
>    prefixes belonging to another Mobile Router.  The Home Agent can
>    prevent such attacks if it maintains the Prefix Table and verifies
>    the Prefix Information provided by the Mobile Router against the
>    entries in the Prefix Table.  However, this verification is done only
>    if the Binding Update contained explicit prefix information in the
>    form of either the Mobile Network Prefix Option or the Mobile Network
>    Prefix Length Option.
> 
>    Each entry in the Prefix Table conceptually contains the following
>    fields:
> 
>     -  The Home Address of the Mobile Router.  This field is used as the
>        key for searching the pre-configured prefix table.
> 
>     -  The Mobile Network Prefix of the Mobile Router associated with
>        the Home Address.
> 
> replace
> >     -  If there are no options in the Binding Update, the Home Agent
> >        figures out which prefixes are assigned to the Mobile Router
> >        from the Pre-configured Prefix Table.  If the Home Agent can not
> >        find the correspondent Mobile Network Prefix, it MUST reject the
> >        Binding Update and send a Binding Acknowledgement with the Status
> >        field set to 143 (Prefix Information unavailable).
> 
> to
>     -  If there are no options in the Binding Update, the Home Agent
>        uses manual pre-configured information to determine the
>        prefixes assigned to the Mobile Router and for setting up
>        forwarding for the Mobile Network.  If there is no information
>        that the Home Agent can use, it MUST reject the Binding Update
>        and send a Binding Acknowledgement with status set to 143
>        (Forwarding Setup failed).
> 
> replace
> >    The Home Agent sets the status code in the Binding Acknowledgement
> >    to '143' (Mobile Network Prefix information unavailable) in order
> >    to indicate the Mobile Router that the received Home Address in the
> >    Binding Update does not match any prefix entry in the pre-configured
> >    prefix table.  This is used in the Implicit case where the Mobile
> >    Router does not include any prefix information in the Binding Update.
> 
> 
> with
> 
>    The Home Agent sets the status code to 143 (Forwarding Setup
>    failed) if it is unable to determine the information needed to setup
>    forwarding for the Mobile Network.  This is used in the Implicit mode
>    where the Mobile Router does not include any prefix information in
>    the Binding Update.
> 
> 
> Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 07 Aug 2003 10:21:46 -0700

> There's still the original question of differentiating implicit and IGP?

??? this was issue 6. please read your own comments.
the concensus was it is a matter of config at the
HA and the HA would be able to distinguish between
implicit mode and running an IGP over the MR-HA 
tunnel.

moreover, it would be a good idea to keep the IGP 
part separate from rest of the specification. I dont
think we have considered all the issues.

> Also, MUST is a bit severe for the 143, ain't it?

MUST is needed. we dont want the MR assuming everything
is fine, when the HA actually couldnt setup forwarding
for the Mobile Network.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 07 Aug 2003 10:21:46 -0700

Vijay