Re: [Seamoby] DoCoMo Implementation Issues with CTP

[Rajeev Koodli <[e-mail]>]

Revise the current definition of `V' flag from

"When set to '00', indicate presence of IPv6
   Previous (New) address only." etc. to

"When set to '00', indicate presence of _MN's_IPv6
   Previous (New) address only. etc.

Also I suggest that the field "Previous (New) Router IP Address"
be revised to "Previous (New) Router IPv4 Address"

And, when `V' is 10, the token calculation should include
both IPv4 and IPv6 addresses. So, to the following,

"First (32, HMAC_SHA1 (Key, (Previous IP address | Replay | Context
      Types))), where Key is the shared secret between the MN and pAR,
      and Context Types includes all the desired contexts for which the
      transfer is desired. In the default scenario, the MN implicitly
      (i.e., even without the knowledge of contexts being present) or
      explicitly requests transfer of all contexts."

add

"When contexts corresponding to both IPv4 and IPv6 addresses are
present (i.e., `V' is 10), the calculation is performed as
First (32, HMAC_SHA1 (Key, (Previous IP v4 address | Previous IPv6
address | Replay | ContextTypes)))."

-Rajeev


James Kempf wrote:

> Rajeev,
>
> Could you suggest some text for the draft that clarifies this point?
>
>             jak
>
> ----- Original Message -----
> From: "Rajeev Koodli" <[e-mail]>
> To: "Raghu" <[e-mail]>
> Cc: "James Kempf" <[e-mail]>; <[e-mail]>
> Sent: Thursday, February 19, 2004 5:01 PM
> Subject: Re: [Seamoby] DoCoMo Implementation Issues with CTP
>
> >
> > Hello Raghu,
> >
> >
> > Raghu wrote:
> >
> > > >
> > > > - When both IPv4 and IPv6 addresses are used in CTD,
> > > >  "Processing the address of the opposite
> > > > version in the stack is complicated. " Could you elaborate on
> > > > this ? I can see that once IP (v4 or v6) stack demultiplexes the
> > > > packet to belong to a CTP client, it would just forward the block
> > > > to a CTP module (a daemon for instance), which could then
> > > > process contexts associated with both the addresses.
> > > >
> > > IP Version flag in the draft indicates whether the IP Version
> > > can be either IPv4 or IPv6 or both(IPv4 & IPv6).
> > > When MN is assigned both IPv4 & IPv6 addresses,
> > > it is assumed that AR also has both IPv4 & IPv6 addresses.
> > > When MN moves, sending two CT messages for the same MN
> > > is unnecessary. Hence to avoid this, either IP version flag
> > >
> >
> > hmm.. This is perhaps a misunderstanding.
> > The `V' bits indicate whether contexts corresponding to
> > both IPv4 and IPv6 addresses (as well as the addresses
> > themselves) are present. The (P)CTD message itself
> > can be either IPv4 or IPv6. You may observe that the
> > Source and Destination IP addresses for all the messages
> > are absent. I cannot say this is intentional, but the result is
> > that the messages themselves can be carried in IPv4 or IPv6
> > packets.
> >
> >
> > > should not support both IPv4 & IPv6 at the same time or
> > > the draft should mention, which IP version to take precedence.
> > >
> >
> > Hopefully, the above explanation clarifies..(i.e., IP version of
> > the packets carrying CTP messages is independent of the
> > `V' bits).
> >
> > Length field increase (below) is okay.
> >
> > -Rajeev
> >
> >
> > >
> > > > - Isn't MTU a consideration in increasing the size of the
> > > >     Length field to 16 bits ?
> > > >
> > >
> > > Since CTP is an application layer program, I guess
> > > supporting upto 16bits is more reasonable for the
> > > following reasons
> > > 1. UDP supports upto 16bits
> > > 2. As more Feature profiles are defined more
> > >     contexts in the same CTP needs to be transferred.
> > >
> > > As per the sections 2.4 & 2.5 in the draft
> > > "message length in units of 8", Padding bytes
> > >  are required for both CDB & CT Messages.
> > > These padding bytes get critical when we are
> > > reaching the maximum size ie 2048 bytes.
> > >
> >
> >


_______________________________________________
Seamoby mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/seamoby