Subject: RE: [Mip6] I-D ACTION:draft-ietf-mip6-nemo-v4traversal-00.txt

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 20 Oct 2005 23:25:46 -0400

Hello Keiichi, 

Thanks for the comments. Responses inline.

 > 
 > - The draft seems discussing two separate issues.
 > 
 > I think, v4traversal and supporting IPv4 HoA/network are different
 > issues.  Don't we need to think an scenario, which doesn't need
 > v4traversal but need IPv4 communication, and vice versa?

=> Absolutely. That's why the draft allows a node to use an IPv4
home address whether it's in an IPv4 or an IPv6 network.

  In the
 > previous discussion (two months ago in the MIP6 mailing list, maybe),
 > you mentioned that separating these two issues add complexity.  

=> Yes.

   But
 > I'm afraid I still don't understand what complexity is added when we
 > divide the above two issues.  It should be helpful if you could show
 > some examples.

=> What I was referring to before was writing two different specs in 
parallel. It's a matter of organisation and working out dependencies 
between documents. One solution can easily address having IPv4 home 
or coa as you can see from this document. 

 > 
 > 
 > - more detailed operational procedure is required
 > 
 >   The draft doesn't describe mobile router/home agent 
 > operation when a
 >   static IPv4 address or IPv4 mobile network prefix is used.  

=> Could you be specific on what is missing from the current
draft in terms of operation? Meaning, as an implementer, when
you read the draft, what more do you need to know to implement it?

 > - typo in page14,
 > 
 > The source and dst addresses described in a BA message are wrong.
 > 
 > >    B. Binding acknowledgement sent by the home agent:
 > >               IPv4 header (src=V4ADDR, dst=HAADDR)
 > >                  [UDP header] (If V4ADDR != V4CoA)
 > >                    IPv6 header (src=V4CoA, dst=HAADDR)
 > >                       Route HRD Type 2
 > >                           HOA (IPv6 home address)
 > >                       Mobility header
 > >                           BA ([IPv4 ACK], NAT DET)
 > 
 > The outer source should be HAADDR and dst should be V4ADDR.
 > The inner source should be HAADDR and dst should be V4CoA.
 > 

=> Thanks, will fix that in the next rev.

 > 
 > - in page 16
 > 
 > >    - If the binding update is accepted for the IPv4 home 
 > address, the
 > >      home agent MUST create a binding cache entry for the IPv4 home
 > >      address/prefix. If a single IPv4 home address were 
 > requested, it
 >                        
 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 > >      MAY be stored in the IPv4-mapped IPv6 address format. The home
 >        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 > >      agent MUST include an IPv4 acknowledgement option in 
 > the mobility
 > >      header containing the binding acknowledgement.
 > 
 > What does the above underlined text mean?  It seems you are 
 > discussing
 > implementation specific thing, which should not be discussed in the
 > specification.

=> The text means that you can store a unicast address in the mapped 
format if you want (hence the MAY). Conceptual implementation issues 
are discussed in most specs actually. See for instance RFC 3775, RFC 2461, 
IPsec RFCs ....etc. 

 > - (minor) terminology
 > 
 >   I don't think the word 'IPv4 home address' is a good wording, since
 >   the word is already used by MIP4.  So, maybe other wording, such as
 >   'IPv4 static address' seems better.

=> Hmm, I don't think MIPv4 will sue us for it :) It seems appropriate
for the use. I'm open to suggestions, but IPv4 static address is not appropriate
IMO given that it is allocated statically or dynamically. 

Hesham

 > 
 > 
 > ---
 > Keiichi SHIMA
 > IIJ Research Laboratory <[email-masked]>
 > KAME Project <[email-masked]>
 > 
 > _______________________________________________
 > Mip6 mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/mip6
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Keiichi SHIMA <[email-masked]>
Date: Mon, 24 Oct 2005 19:11:34 +0900 (JST)

Hello Hesham,

Please find my comments inline..

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 20 Oct 2005 23:25:46 -0400
> or coa as you can see from this document. 

My point is that having IPv4 CoA and Having IPv4 HoA is different
things and they are orthogonal.  (I think my explanation is not
good...)

Let's consider to implement IPv6 mobile node which supports IPv4
access network, but don't support IPv4 HoA.  Which RFC should we
support?  If we continue to discuss the different things in one draft,
we must also make it clear which section(s) is necessary to implement
what feature.  But I feel it is a bad idea to specify features in such
a manner.  Easier way to make it clear is to divide the specification...

> you read the draft, what more do you need to know to implement it?

Frankly speaking, I think I can implement the function from the text,
since I already have much knowledge of MIP implementation.  But maybe
the draft at least should mention about

- home agent operation when IPv4 mobile network is behind a mobile
  router
- mobile router operation which has IP4 mobile network
- proxy operation on a home agent when a mobile router use an IPv4
  home address

I'll attach some text from my draft (draft-shima-nemo-v4prefix-01.txt
which should be published in a few days).  Although I don't think the
text can be used as it is, but, I think the same kind of specification
is useful to say.

--quote start-------------------------------------------------------------
6.  Mobile Router operation

   A mobile router which has IPv4 networks on its ingress interface can
   include the IPv4 Mobile Network Prefix option in a Binding Update
   message to its home agent.  After receiving a successful
   acknowledgment from the home agent, the mobile router adds a route
   entry which indicates that all traffic from the IPv4 networks is
   forwarded to the tunnel interface created between the mobile router
   and its home agent.

   A mobile router will receive a Binding Acknowledgment message with
   the IPv4 Mobile Prefix Registration Status Option when a home agent
   supports this extension.  If the Binding Acknowledgment does not
   include the option, the IPv4 prefix registration cannot be used.

   After successful registration of IPv4 network prefixes, a mobile
   router forwards all IPv4 packets which source address is in the range
   of the registered IPv4 prefix to its home agent using an IPv6 tunnel
   created between the mobile router and its home agent, when those IPv4
   packets are received from the ingress interface of the mobile router.
   On the other hand, when the mobile router receives IPv4 packets from
   the tunnel and the destination address of the internal packet is in
   the range of the registered IPv4 prefix, the mobile router forwards
   those IPv4 packets to its ingress interface.

8.  Home Agent operation

   A home agent which supports the IPv4 Mobile Network Prefix Option
   will add a route entry for the IPv4 network prefix when it receives a
   Binding Update message with the option.  A Binding Acknowledgment
   message sent from the home agent must include the IPv4 Mobile Prefix
   Registration Status Option to indicate the processing status of the
   received IPv4 Mobile Prefix Option.

   When a home agent accept the IPv4 Mobile Network Prefix Option, the
   status field of the IPv4 Mobile Network Registration Status Option
   must be set to 0 indicating success.  Otherwise, the status code must
   be filled with an error code as described in section Section 5.2.

   After successful registration of IPv4 prefixes, a home agent start
   forwarding IPv4 packets which destination address is in the range of
   registered IPv4 prefix to the tunnel to the mobile router which
   registered the corresponding IPv4 prefix.  At the same time, the home
   agent also start accepting IPv4 packets sent from the tunnel which
   source address is in the range of the registered IPv4 prefix and
   start forwarding to the IPv4 internet.

   If the Prefix Length field in the incoming IPv4 Mobile Network Prefix
   Option is equal to 32, a home agent treats the value in the IPv4
   Mobile Network Prefix field as an IPv4 Mobile Address.  The address
   must be one of addresses of the IPv4 network that the home agent is
   attached to.  If the validation succeeds, a home agent starts
   proxying the IPv4 node identifier included in the option (after
   checking there is no other nodes which is using the IPv4 address).  A
   home agent will intercept all IPv4 packets delivered to the home
   network if the destination address of the packets is equal to the
   IPv4 Mobile Address.  These intercepted packets will be forwarded to
   the mobile host using an IPv6 tunnel created between the home agent
   and the mobile host.  If a home agent receives IPv4 packets which
   source address is the IPv4 Mobile Address from the IPv6 tunnel
   interface, a home agent will forward the packets to the IPv4
   Internet.
--quote end----------------------------------------------------------------

> are discussed in most specs actually. See for instance RFC 3775, RFC 2461, 

Some RFC do.  But I just feel that kind of definition is nothing to do
with the protocol and I don't think it is necessary to mention in RFC
(which defines a protocol), IMHO.

> IMO given that it is allocated statically or dynamically. 

Ah, yes.  'static' might be a wrong choice.  It may not cause any
confusion, as long as we use the word 'IPv4 home address' only in
Mobile IPv6 context.  So, then, I don't mind to keep it until we face
any kind of problem.

---
Keiichi SHIMA

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Oct 2005 16:37:29 +0200

> home address whether it's in an IPv4 or an IPv6 network.

And don't you think that there is a need for a node in a moving network
to use IPv4 fixed address and the Mobile Router to do NEMO and no MIP6?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Oct 2005 16:40:05 +0200

> a manner.  Easier way to make it clear is to divide the specification...

Right, I also think the current draft still tries to address too many
scenarios.  I would keep in it only running MIP6 over a v4-only access
network, with NAT traversal.  I would separate from it all NEMO aspects
be it v4 or v6, I would separate also giving v4-home-address through
MIP6 through v4-only access network.

Alex