Subject: RE: [Mip4] draft-ietf-mip4-gen-ext-03.txt

From: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 13 Nov 2007 12:00:58 -0500

We have yet to arrive at a conclusion on whether to
proceed with this draft or document a DHCP-based
solution.

It was recently pointed out to me that the DHCPINFORM
message may have some issues with reverse tunneling
due to the need to use encapsulating delivery style.
People might be concerned about the extra overhead
of this requirement.

I'd like to ask members of the DHCP community especially
to please comment to both lists; it may help to read
RFC 3024 before doing so.

I'd like to have this issue resolved before Vancouver.

-Pete

Chowdhury, Kuntal wrote:
> Hi Pete,
> 
> I think the source of the confusion is the use of DHCP options. The
> initial version of this I-D did not propose to use DHCP options at
> all.  
> The proposal contained a few possible host config parameters that we
> would have defined. However, someone saw the light, and suggested
> that instead of redesigning the host config options from scratch, why
> not we used the options and the format of the options carrying config
> info as defined in DHCP. It made sense; hence we decided to accept
> that approach.     
> 
> Now, I see that people are mixing the use of DHCP protocol with MIP4
> host config options. I think this is a digression that we should
> avoid.  
> We need to understand the scope of the I-D. It does not rule out
> other ways to do host configuration when the MN is using MIP4. It
> defines _a_ way that is Mobile IP specific. It is also the most
> efficient one from the number of round trips point of view.   
> 
> When you say that running DHCP inside MIP4 tunnel allows for a single
> protocol to be used whether the MN is at home or visiting, I have a
> question. How is it possible for the MN to fetch config info from the
> visited network when RT is negotiated and enforced at the FA?   
> 
> BTW, the approach specified in the draft-ietf-mip4-gen-ext-03.txt
> allows the use of a single protocol i.e. MIP4 to be used to fetch
> config info from home and visited networks, not to mention with fewer
> number of messages.   
> 
> Another issue that we need to think about the use of DHCP inside MIP4
> tunnel is security. We cannot prohibit the MN to run DHCPINFORM only,
> right? The MN may start doing IP address config (lease and release).
> How to secure these DHCP messages? If we intend to only allow the MN
> to send DHCPINFORM, how do we prevent it from sending other DHCP
> messages?     
> 
> AFAIK, RFC 3118 is not widely implemented and used. Even if it is, we
> can't expect the MIP4 implementations to start implementing RFC 3118
> just to get a few config info from the home domain.  
> 
> Regards,
> Kuntal
> 
>> -----Original Message-----
>> From: McCann Peter-A001034 [mailto:[email-masked]]
>> Sent: Tuesday, July 31, 2007 9:01 AM
>> To: [email-masked]; [email-masked]
>> Subject: [Mip4] draft-ietf-mip4-gen-ext-03.txt
>> 
>> A question has arisen during the last call for
>> draft-ietf-mip4-gen-ext-03.txt.
>> 
>> The draft includes the following text:
>> 
>>     There are mechanisms
>>     such as DHCP for the mobile node to configure information from
>>     the foreign network, but not from the home network when the
>>     mobile node is not attached to the home network.
>> 
>> However, this may not be strictly true.  In particular, it might be
>> possible to use a DHCPINFORM message through the tunnel that was
>> established with Mobile IP, thus eliminating the need to encode DHCP
>> options inside Mobile IP messages.
>> This would allow for a single configuration protocol to be used
>> whether the MN is at home or visiting.
>> 
>> I think we may have touched on this question during our last
>> chartering discussion but we might not have explored all the
>> ramifications.  Please, if you have an opinion either way express it
>> now and give some background as to why you think so.
>> It is possible that we might turn this draft into a BCP-like document
>> for how to configure and run DHCP over the tunnel to the home
>> network. 
>> 
>> -Pete

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Ralph Droms <[email-masked]>
Date: Thu, 15 Nov 2007 14:33:23 -0500

Pete - I notice that there are no references to other Mobile IPv4  
documents in this draft, which makes it difficult for someone like  
myself who is relatively uninformed about Mobile IPv4 to know how to  
get more context about Mobile IPv4 extensions, the Mobile IPv4  
message exchanges, etc.

I tried reading RFC 3024 and, perhaps not giving myself enough time  
to understand the doc fully, I didn't see the problem with using  
DHCPINFORM with reverse tunneling.

I wasn't able to answer another question for myself: what is the  
address assignment model and does critical information like subnet  
mask and default router have to be delivered at the same time as any  
assigned addresses?

- Ralph

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 15 Nov 2007 15:24:39 -0500

Hi, Ralph,

Thanks for the note.  It seems from your comments that we have
a bit of information sharing to do in order to reach a proper
consensus on this issue.

The basic Mobile IPv4 protocol is defined in RFC3344, which is
currently being revised in draft-ietf-mip4-rfc3344bis-05.txt.
It is a long draft, but the basics are that a Mobile Node sends
a Registration Request to the Home Agent, possibly via a Foreign 
Agent.  The Home Agent installs a mobility binding for the
Mobile Node and returns a Registration Reply.  Both Requests
and Replies can be augmented with Extensions, which are documented
in various RFCs.  For address assignment, it's probably best 
to take a look at RFC2974 which defines the Network Access Identifier
extension.  When this extension is included, the Home Address
in the Registration Request can be zero, and the idea is that
the Home Agent will allocate an address and return it in the
Registration Reply.

As for your question about default router and subnet mask:
Mobile IP has its own method of determining a default router
when the MN is away from home (see section 4.2.1 of rfc3344bis),
and the MN behaves just as any other non-mobile host when it
is on its home subnet.  So, base Mobile IP does not need to
carry a default router as part of Mobile IP messaging.

As for the subnet mask, we don't currently have a way of 
propagating this in Mobile IP.  Current practice is to
assume that the mask is manually configured.  Note that
when a mobile node is away from home, it doesn't usually
need to make a decision about where to send the packet
based on subnet mask: it always sends packets to the link
layer address of the FA (for FA-located CoA) and isn't 
supposed to run ARP.  For co-located CoA, the MN will
typically encapsulate and send all home-network packets
to the HA.  In this case a smart mobile node might also
allow direct Internet access from the visited link in
parallel with the reverse tunnel, but usually this is
not the case.

When reverse tunneling ala RFC 3024 is used (as it is in most 
major deployments of MIP), the MN has a choice about whether
to negotiate "encapsulated delivery style" on the last hop
link.  It must negotiate this if it wants to send broadcast
datagrams (of which I think the DHCPDISCOVER is one) to the
home network.  In this case, an FA will look at each packet,
and reverse tunnel the ones that are so encapsulated and send
other packets directly.  The problem I was trying to point 
out is that this extra encapsulation would be present on 
every packet sent to the home network, which might cause
a lot of overhead on the link between the MN and FA.  If
this is a wireless link, this overhead is especially onerous.

Please post if you have any remaining questions or if I 
have misunderstood the DHCP message flow.

-Pete

Ralph Droms wrote:
>> We have yet to arrive at a conclusion on whether to proceed with this
>> draft or document a DHCP-based solution.
>> 
>> It was recently pointed out to me that the DHCPINFORM message may
>> have some issues with reverse tunneling due to the need to use
>> encapsulating delivery style. People might be concerned about the
>> extra overhead of this requirement. 
>> 
>> I'd like to ask members of the DHCP community especially to please
>> comment to both lists; it may help to read RFC 3024 before doing so.
>> 
>>> all. The proposal contained a few possible host config parameters
>>> that we would have defined. However, someone saw the light, and
>>> suggested that instead of redesigning the host config options from
>>> scratch, why not we used the options and the format of the options
>>> carrying config info as defined in DHCP. It made sense; hence we
>>> decided to accept that approach. 
>>> 
>>> avoid. We need to understand the scope of the I-D. It does not rule
>>> out other ways to do host configuration when the MN is using MIP4.
>>> It defines _a_ way that is Mobile IP specific. It is also the most
>>> When you say that running DHCP inside MIP4 tunnel allows for a
>>> single protocol to be used whether the MN is at home or visiting, I
>>> have a question. How is it possible for the MN to fetch config info
>>> from the visited network when RT is negotiated and enforced at the
>>> FA? 
>>> 
>>> config info from home and visited networks, not to mention with
>>> fewer number of messages. 
>>> 
>>> Another issue that we need to think about the use of DHCP inside
>>> MIP4 tunnel is security. We cannot prohibit the MN to run
>>> DHCPINFORM only, right? The MN may start doing IP address config
>>> (lease and release). How to secure these DHCP messages? If we
>>> intend to only allow the MN to send DHCPINFORM, how do we prevent
>>> it from sending other DHCP messages? 
>>> 
>>> AFAIK, RFC 3118 is not widely implemented and used. Even if it is,
>>> we can't expect the MIP4 implementations to start implementing RFC
>>> 3118 just to get a few config info from the home domain.
>>> 
>>> Regards,
>>> Kuntal
>>> 
>>>> established with Mobile IP, thus eliminating the need to encode
>>>> DHCP options inside Mobile IP messages.
>>>> ramifications.  Please, if you have an opinion either way express
>>>> it now and give some background as to why you think so.
>>>> It is possible that we might turn this draft into a BCP-like
>>>> document for how to configure and run DHCP over the tunnel to the
>>>> home network. 
>>>> 
>>>> -Pete

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 19 Nov 2007 13:27:36 +0100

Hi Ralph and all,

I have only one small comment regarding Pete's excellent
exposition, inline below:

> Hi, Ralph,
...

> this is a wireless link, this overhead is especially onerous.

Note, though, that there is currently a proposal in 
draft-chakrabarti-mip4-mcbc-01 which if pursued will remove
the extra encapsulation on all packets:
  http://www.tools.ietf.org/html/draft-chakrabarti-mip4-mcbc-01

Regards,

	Henrik

---

From: "Parviz Yegani (pyegani)" <[email-masked]>
Date: Mon, 19 Nov 2007 13:17:29 -0800

-----Original Message-----
From: Henrik Levkowetz [mailto:[email-masked]] 
Sent: Monday, November 19, 2007 4:28 AM
To: McCann Peter-A001034
Cc: [email-masked]; [email-masked]; Ralph Droms (rdroms)
Subject: [dhcwg] Re: [Mip4] draft-ietf-mip4-gen-ext-03.txt

Hi Ralph and all,

I have only one small comment regarding Pete's excellent exposition,
inline below:

...

> When reverse tunneling ala RFC 3024 is used (as it is in most major 
> deployments of MIP), the MN has a choice about whether to negotiate 
> "encapsulated delivery style" on the last hop link.  It must negotiate

> this if it wants to send broadcast datagrams (of which I think the 
> DHCPDISCOVER is one) to the home network.  In this case, an FA will 
> look at each packet, and reverse tunnel the ones that are so 
> encapsulated and send other packets directly.  The problem I was 
> trying to point out is that this extra encapsulation would be present 
> on every packet sent to the home network, which might cause a lot of 
> overhead on the link between the MN and FA.  If this is a wireless 
> link, this overhead is especially onerous.

Note, though, that there is currently a proposal in
draft-chakrabarti-mip4-mcbc-01 which if pursued will remove the extra
encapsulation on all packets:
  http://www.tools.ietf.org/html/draft-chakrabarti-mip4-mcbc-01

Yes, an update (-02) has been posted.

Rgds,
Parviz

> Please post if you have any remaining questions or if I have 
> misunderstood the DHCP message flow.

Regards,

	Henrik

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

---

From: Hans Sjöstrand <[email-masked]>
Date: Mon, 26 Nov 2007 15:59:31 +0100

Hi Pete,

Some thoughts from an implementation perspective.

An MN could theoretically suffice without default router and subnet 
mask. However, most MN implementations do require it. What MN OS accepts 
an address without gateway and subnet mask? Not a routing table I know 
of atleast. An MN needs this information. And most often accompanied 
with other obvious information, e.g. dns server address.

Any MN could, in most cases atleast, get this configuration by first 
doing a registration, and subsequently do a dhcp inform in that tunnel. 
However, there are loads of reasons why it's a lot more efficient if 
this was done in one operation, not in two. Kent mentioned five reasons, 
all very valid.

And in comparison with a life of an PMA, an MN has a relatively stress 
free life. A MN only accounts for one set of dhcp options and values. A 
PMIP client has to perform the same task but for hundreds or possible 
thousands of dhcp clients. A PMIP client implementation then has to keep 
outstanding states and depend on various DHCP servers in various home 
networks. I really looking forward to an approved ietf-mip4-gen-ext and 
the transactional safety it will provide.

So, in my mind atleast. it's all quite possible to do with tunneled 
dhcp. But I don't recommend it. And I see very little reason why not do 
it proper and provide mobile ip with this tool that in my mind will 
increase scalability, authentication and robustness for the entire 
mobility solution.

Best regards
/// Hasse