Subject: [mobile-ip] Revised agenda for: MIP4 - Mobility for IPv4 BOF

From: <[email-masked]>
Date: Tue, 8 Jul 2003 17:34:18 -0500

Hello,

Below is the revised agenda for the MIP4 BOF.

-Basavaraj

------------------------------------------------------------------

Mobility for IPv4 BOF (mip4)

Monday, July 14 at 0900-1130
==============================

CHAIRS:	Basavaraj Patil <[email-masked]>
	Gabriel Montenegro <[email-masked]> 
	Phil Roberts <[email-masked]>

AGENDA:

NOTE: MIP4 is in the process of being approved as a working group.
      Final approval MAY happen before Vienna IETF. Details,
      work items, chairs, etc are likely to change.

1.      Charter discussion: 15 min
	Chairs

2.      VPN problem statement update: 20 min
        I-D: draft-ietf-mobileip-vpn-problem-statement-req-03.txt
        Presenter: Gopal Dometty
	The I-D which will be completing WG LC before the meeting has
        been revised following reviews by the Mobile IP security
        advisor (Radia Perlman). The intent is to provide a status
        update on the problem statement as well as discuss any LC
        comments/issues that may be identified

3.      VPN solutions discussion: 20 min
        I-D: draft-ietf-mobileip-vpn-problem-solution-02.txt
        Presenter(s): Sami Vaarala or Farid Adrangi
	The design team has discussed a number of options in the
        solution space. This agenda item is aimed at presenting the
        conclusions reached and the reasoning behind the choice being
        made. 

4.      Dynamic HA discussion: 20 min
        I-D: draft-kulkarni-mobileip-dynamic-asignment-01.txt
        Presenter: Milind Kulkarni
	This agenda item is intended as a discussion item to gauge WG
        interest in the idea of dynamic Home Agent assignment and to
        consider this as a WG item.

Status of WG I-Ds (Mobile IPv4 related):
1. draft-ietf-mobileip-reg-revok-07.txt
   I-D has been approved and is currently on RFC editors queue.
2. draft-ietf-mobileip-aaa-key-12.txt
   WG last call issued on May 23rd. 
   A few comments have been received. Resolution of these comments in
   progress. 
3. draft-ietf-mobileip-lowlatency-handoffs-v4-05.txt
   New revision of I-D submitted. (Previous version had expired)
   I-D to be submitted to ADs for consideration as experimental before
   IETF57. 
4. draft-ietf-mobileip-rfc3012bis-05.txt
   Review comments being addressed. 
   WG last call after IETF57
5. draft-ietf-mobileip-aaa-nai-05
   WG LC completed. Needs to be submitted to ADs for IESG
   consideration.
6. draft-ietf-mobileip-vpn-problem-statement-req-03
   WG last call issued on June 30th.
7. draft-ietf-mobileip-vpn-problem-solution-02
   Work in progress

DESCRIPTION:

IP mobility support for IPv4 nodes (hosts and routers) is specified in
RFC3344. RFC 3344 mobility allows a node to continue using its "permanent"
home address as it moves around the internet. The Mobile IP protocols support 
transparency above the IP layer, including maintenance of active
TCP connections and UDP port bindings. Besides the basic Mobile IPv4
(MIPv4) protocols, several other drafts deal with concerns such as
optimization, security, extensions, AAA support and, deployment
issues. 

Mobile IPv4 is currently being deployed on a wide basis (e.g., in cdma2000
networks). The scope of the deployment is on a fairly large scale and 
accordingly, the MIP4 WG will focus on deployment issues, and
on addressing known deficiencies and shortcomings in the protocol that
have come up as a result of deployment experience.
Specifically the working group will complete the work items to facilitate
interactions with AAA environments, interactions with enterprise
environments when Mobile IPv4 is used therein, and updating existing
protocol specifications in accordance with deployment needs and advancing
those protocols that are on the standards track.

Work expected to be done by the MIP4 WG as proposed by this charter is
as follows:

1. MIPv4 has been a proposed standard for several years. It has been
   adopted by other standard development organizations and has been
   deployed commercially. One of the next steps for the WG is to advance
   the protocol to draft standard status. As part of advancing base
   Mobile IP specs to DS, the Mobile IPv4 NAI RFC (2794) will also be
   progressed towards DS.

2. Key exchange using AAA infrastructures for setting up security
   associations defined in RFC3344 will be completed.

3. The AAA WG which is currently dealing with the Diameter Mobile IP
   application requires the AAA NAI for Mobile IPv4. This work will
   be completed by the WG. The MIP4 WG will also work with the AAA WG
   to ensure that the Diameter Mobile IP application is aligned with
   WG requirements.

4. Dynamic home agent assignment via a lightweight mechanism has been
   proposed and the WG will take on the task of completing this. The
   ability to switch the home agent assigned to a mobile node will also
   be considered as part of this task.

5. Work items that are pending from the previous Mobile IP WG and will be
   completed by the MIP4 WG are RFC3012bis (Challenge-response mechanism),
   low-latency handover draft to experimental status and the completion
   of the MIB for the revised base Mobile IP specification (2006bis).

6. The MIP4 WG also complete the work on Mobile IPv4 interactions in VPN
   scenarios. This work will involve identifying the requirements and
   a solution development for Mobile IPv4 operation in the presence of
   IPsec VPN's. 

Other potential work items may be identified in the future but will
require an appropriate recharter.

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 09 Jul 2003 17:48:36 +0200

----------------------------
Mobility for IPv6 [MIP6] BOF
----------------------------
Agenda:
-------
WEDNESDAY, July 16, 2003, 0900-1015

NOTE: MIP6 is in the process of being approved as a working group.
       Final approval MAY happen before Vienna IETF. Details,
       work items, chairs, etc are likely to change.

1. 	Charter discussion: 10 min
	Chairs

2. 	Thoughts on Bootstrapping a mobile node securely: 15 min
	I-D: none
	Presenter: Chairs
	There are still some unanswered questions on how a MN can remotely
	configure itself in the presence of changing prefixes, obtain
	a home address (perhaps dynamically generated via RFC 3041) and
	home agent, and, most importantly, how it can obtain a security
	association to protect its MN-HA signaling. Another related
	question is to define the relationship (if any) with ENROLL.

3.	Alternate HA-MN Signaling Security Ideas: 20 min
	I-D: none
	Presenters: Jari Arkko, Charlie Perkins
	The base spec requires draft-ietf-mobileip-mipv6-ha-ipsec-06.txt.
	However, this document has generated lots of discussion on
	alternate ways to configure the signaling protection using IPsec
	(and IKEv1/IKEv2), as well as without using IPsec.
	These discussions will be summarized and presented to the WG
	for discussion and to set a future course of action.

4.	Multiple Care-of Address Registration on Mobile IPv6: 10 min
	I-D: draft-wakikawa-mip6-multiplecoa-01.txt
	Presenter: Ryuji Wakikawa
	This item has generated discussion lately, not all
	strictly related to just this draft (multiple
	CoA's, flow movement, multiple interfaces). These
	discussions will be summarized in order to determine
	how to proceed.

5.	Extension to Advanced Socket API for Mobile IPv6: 10 min
	I-D: draft-chakrabarti-mobileip-mipext-advapi-01.txt
	Presenter: Samita Chakrabarti
	Summary of latest discussions and changes to this draft,
	based on discussion on [email-masked]. Should the
	WG consider it for informational?

6.	Backbone interoperability testing: 10 min
	I-D: none
	Presenter: [email-masked]
	A group of interested folks (ETSI, TAHI, etc) have been making
	progress towards establishing a backbone for MIPv6 testing on
	the Internet (discussed on the [email-masked] alias). A
	quick update will be presented.

Status of WG I-Ds (Mobile IPv6 related):
1. draft-ietf-mobileip-ipv6-24.txt
	Approved by IESG for proposed standard
2. draft-ietf-mobileip-mipv6-ha-ipsec-06.txt
	Last discussions with IESG ongoing...

Charter:
--------

Mobile IPv6 specifies routing support to permit IPv6 hosts to
continue using its "permanent" home address as it moves around
the Internet. Mobile IPv6 supports transparency above the IP
layer, including maintenance of active TCP connections and UDP port
bindings. The specifications for these mechanisms consist of:

    draft-ietf-mobileip-ipv6-xx (or RFC) and
    draft-ietf-mobleip-mipv6-ha-ipsec-xx (or RFC)

The protocol currently consists of the base specification (as per the
above documents), which contain the base elements for enabling IPv6
mobility. During the development of the base protocol, a few
additional features were identified as necessary to facilitate
deployment (described below).

The primary goal of the MIP6 working group is to improve the base
specification and to work on items that are deemed critical to getting
MIPv6 deployable on a large scale.  Specifically, this includes:

1) Refining the base specifications based on experience of initial
    implementations and interoperability testing.

2) Splitting up the two base specifications into smaller, modular,
    interworking pieces. For example, features such as Route
    Optimization, HA Discovery, Movement detection and renumbering of
    the home link, which are currently a part of the base
    specification, may be the subject of separate specifications.

3) Work on items identified during the development of the base
    specification. Specifically:

     - A bootstrap mechanism for setting up security associations
       between the MN and HA that would enable easier deployment of
       Mobile IPv6.

     - Improving home agent reliability: in the event of a home agent
       crashing, this would allow another home agent to continue
       providing service to a given mobile node.

     - Support for the MN's changing addresses either because of
       renumbering in its home network or because it periodically
       changes addresses (perhaps via rfc3041)

     - Return-routability is the basic mechanism for
       route-optimization. There may be other means for establishing a
       security association between the mobile node and the
       correspondent node. The working group will also specify how to
       effect route-optimization using these methods. Particularly
       interesting are methods more secure than return-routability, as
       these would allow for a reduction in signaling load.

     - multicast support. Further specification work may seek to further
       specify MLDv2 proxying at the home agent, handoff survival of
       local (at a foreign link) multicast sessions, addressing
       bandwidth inefficiency inherent in the home agent's unicasting
       multicast packets through the tunnel to the mobile node, for example.

It should be noted that there are potential optimizations that might
make mobile IP more attractive for use by certain applications (e.g.,
making handovers "faster"). The latter category of optimizations is
explicitely out-of-scope at this time; this WG will focus on issues
for which there is strong consensus that the work is needed to get
basic mobility deployable on a large scale.

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 09 Jul 2003 17:49:12 +0200

-------------------------------------------------------------------
MIPv6 Signaling and Handoff Optimization Working Group [MIPSHOP] BOF
-------------------------------------------------------------------
Agenda:
-------
WEDNESDAY, July 16, 2003, 1015-1130 Morning Sessions

NOTE: MIPSHOP is in the process of being approved as a working group.
       Final approval MAY happen before Vienna IETF. Details,
       work items, chairs, etc are likely to change.

1.	Charter Discussion: 15 min
	I-D: none
	Presenters: Chairs

2.	DNA interactions: 10 min
	I-D: none
	Presenter: Greg Daley
	The Detecting Network Attachment (DNA) BOF will deal with
	issues of how to quickly enable a node to obtain
	presence on a new link. Several such optimizations
	have been discussed to improve handoff (OptiDAD, aDAD,
	etc). These may be further worked on by DNA.
	DNA may also deal with movement detection issues that are
	useful in the context of fast handoffs. This slot
	will allow for discussion on how best to coordinate with
	these DNA efforts which are of utmost importance to
	MIPSHOP.

3.	FMIPv6 Update: 15 min
	I-D: draft-ietf-mobileip-fast-mipv6-06.txt
	Presenter: Rajeev Koodli
	Summary of the latest changes, and specially
	time to clarify and discuss the latest exchanges on the
	list concerning alternatives around address assignment.

4 	HMIPv6 update and lmm-requirements: 15 min
	I-D: draft-ietf-mobileip-hmipv6-08.txt
		draft-ietf-mobileip-lmm-requirements-03.txt
	Presenter: Hesham Soliman
	Latest changes to the draft, in particular, the
	OCOT (on-link care-of address test) addition.
	Also, review of HMIPv6 in the light of lmm-requirements.

5.	Implementation reports: 20 min
	I-D: none
	Presentors: Nokia (Rajeev Koodli), Docomo (James Kempf)
		and Monash University (Nick Moore or Greg Daley)
	This slot allows implementors to report on their work
	with particular attention to lessons learned,
	areas found to be troublesome, etc.

Status of WG I-Ds (MIPSHOP related)
draft-ietf-mobileip-hmipv6-08.txt
draft-ietf-mobileip-fast-mipv6-06.txt
draft-ietf-mobileip-lmm-requirements-03.txt
	All, work in progress

Charter:
--------

Mobile IPv6 specifies routing support to permit IP hosts using IPv6 to
move between IP subnetworks while maintaining session continuity. Mobile
IPv6 supports transparency above the IP layer, including maintenance of
active TCP connections and UDP port bindings.

To accomplish this, the mobile node notifies its home agent of the
current binding between its  home address and its  care of address. This
binding allows a mobile node to maintain connectivity with the Internet
as it moves between subnets. However, packets between the mobile node
and a correspondent node incur sub-optimal triangle routing through
the home agent.  To avoid this, a mobile node can optionally optimize
routing by performing a binding update with the correspondent node.

Depending on what steps a mobile node must perform on a new subnet, the
lag between when the mobile node has layer 2 connectivity and when it
begins sending and receiving packets on the new link may be substantial. A
mobile node must first detect at layer 3 that its point of attachment has
changed, then it must perform configuration on the new link, including
router discovery and configuring a new care of address. After that,
the mobile node must perform binding updates with the home address and
any correspondent nodes.  Any packets between the correspondent node
and the mobile node sent or in-flight during this time arrive at the
old care of address, where they are dropped since the mobile node no
longer has link connectivity with the old subnet. Such packet loss may
have significant adverse effects.

The Mobile IP Working group has been developing two technologies to
address the issues of signaling overhead and handoff latency/packet loss.

These technologies are :

    - Hierarchical Mobile IPv6 mobility management (HMIPv6)

	This deals with reducing the amount and latency of signaling
	between a MN, its Home Agent and one or more correspondents by
	introducing the Mobility Anchor Point (MAP) (a special node
	located in the network visited by the mobile node).  The MAP
	acts somewhat like a local home agent for the visiting mobile
	node by limiting the amount of signalling required outside the
	MAP's domain.

    - Fast Handovers for Mobile IPv6 (FMIPv6)

	This reduces packet loss by providing fast IP connectivity as
	soon as a new link is established. It does so by fixing up the
	routing during link configuration and binding update, so that
	packets delivered to the old care of address are forwarded to the
	new. In addition, FMIPv6 provides support for preconfiguration of
	link information (such as the subnet prefix) in the new subnet
	while the mobile node is still attached to the old subnet. This
	reduces the amount of preconfiguration time in the new subnet.

These technologies can be used separately or together to reduce or
eliminate signaling overhead and packet loss due to handoff delays in
Mobile IPv6.

The MIPSHOP Working Group will use the work begun in the Mobile IP
Working Group on HMIPv6 and FMIPv6 as a basis for continued work in
these technologies.

In addition to the above bases for protocol proposals, the MobileIP
working group developed a set of requirements for "Localized Mobility
Management (LMM)", whereby a Mobile Node is able to continue receiving
packets in a new subnet before the corresponding changes in either the
Home Agent or Correspondent Node binding.  The MIPSHOP working group
will further refine these requirements, and subsequently use them to
ensure that they are met by the protocol proposals being developed.

The working group may engage in the following work:

    - Selection of a default security protocol to secure binding
      updates between the mobile node and the old access router in FMIPv6.

    - Refining the scope of Fast Handoff to address only the most
      common scenarios

    - Applicability of FMIPv6 in the case of 802.11 networks

    - Address security for binding updates in HMIPv6

    - Definition of a MAP discovery protocol for HMIPv6 that does not
      require modification to routers.

Because work ongoing or originating in other working groups may suggest
changes or alternative designs for HMIPv6 and FMIPv6, these specifications
will be advanced as Experimental RFCs until more experience is obtained
with IP mobility in IPv6.  This implies that in the future, the working
group may be rechartered to pursue other experimental specifications as
well as standards track specifications.

---

From: Kuntal Chowdhury <[email-masked]>
Date: Fri, 11 Jul 2003 14:33:22 -0500

I Request to add the following in the "Work expected to be done by the MIP4 
WG..." list:

7. MIPv4 messages to exchange configuration options. The MN may request some 
configuration options such as session manager address, DNS server address etc. 
via MIPv4 messages.

We submitted a draft on this long time ago. There was some limited discussion on 
the MIP list. The current version (-02) is at:

http://www.ietf.org/internet-drafts/draft-bharatia-mobileip-gen-mipv4-ext-02.txt

-Kuntal

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 13 Jul 2003 13:00:45 +0200 (CEST)

> configuration options such as session manager address, DNS server address >
etc.  via MIPv4 messages.

I don't understand why that would be necessary. The DHCPv4 protocol
can operate over the IP-in-IP between the MN and HA; although
DHCPv4 implementations might need tweaking.

  Erik

---

From: Mike Borella <[email-masked]>
Date: Sun, 13 Jul 2003 09:10:27 -0700 (PDT)

Its not always the case that MIPv4 mobiles also
support DHCP.  In these situations, using an alternate
method, such as the one proposed, is a decent
engineering solution.

Mike

> DHCPv4 implementations might need tweaking.

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 13 Jul 2003 21:38:38 +0200 (CEST)

> method, such as the one proposed, is a decent

But there is some experience that having multiple methods/protocols
for accomplishing the same thing reduces the probability of things
interoperating.

So why not pick one and only one way to do this?

  Erik

---

From: Mike Borella <[email-masked]>
Date: Sun, 13 Jul 2003 18:22:05 -0700 (PDT)

> So why not pick one and only one way to do this?
A large number of commercially-deployed MIP services
currently are using MIP extensions for configuration. 
That's not to say that DHCP is a bad idea, but there
is a much less painful way to solve the problem.

Mike

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 14 Jul 2003 09:37:22 +0200 (CEST)

> currently are using MIP extensions for configuration. 

You mean proprietary extensions I assume.
Propritery extensions are less likely to achieve interoperability.

> is a much less painful way to solve the problem.

Depends when pain is allocated and to whom it is allocated.

Having more than one way to do the same thing means that some pain
is allocated to the users - unless everybody implements all ways
there will be less interoperability - and some pain allocated to
the implementors and deployers by implementing and/or deploying more
than one approach.

Switching from a proprietary approach to a standard one, whether there
is one or multiple standardized approaches, will incur some cost
for those that have implemented or deployed a proprietary solution.
That cost will be non-zero unless you assume that the standard will
be a rubber stamp of some (all?) proprietary solutions.

Thus your pain assesment might not be accurate.

   Erik

---

From: Mike Borella <[email-masked]>
Date: Mon, 14 Jul 2003 05:00:15 -0700 (PDT)

> be a rubber stamp of some (all?) proprietary

We're talking standard solutions here, DHCP vs. MIP
extensions.  I am pointing out that it is much simpler
to have MIP return DNS addresses than implementing
DHCP where it does not currently exist and is probably
not needed.  Doing the DHCP would entail more
development effort on the mobile, FA and HA than MIP
extensions.  Therefore in order to solve the problem
in an expeditious fashion, it makes sense to me to use
MIP extensions.

Mike

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 14 Jul 2003 14:44:38 +0200 (CEST)

> in an expeditious fashion, it makes sense to me to use

But DHCP with the needed options already exist as a standard, even if
it is not implemented in certain devices.
Thus going down the path of adding DNS related information to MIP with
result in their being two ways to get DNS addresses; DHCP and MIP.

Also, what will happen when folks discover that there is also a need
to know the address of the SIP proxy? There is already a DHCP option for
this so some folks might use DHCP for it, but others might want to extend
MIP to also carry that information.
(The reason I use SIP proxy address as an example is because there was
a recent proposal to add such an option to PPP for much the same
reasons as you are using, and the PPPEXT WG thought that was a bad idea
for similar reasons to the ones I've brought up.)

Expediuous doesn't mean low cost over the lifetime of the solution.

  Erik

---

From: Kuntal Chowdhury <[email-masked]>
Date: Mon, 14 Jul 2003 09:12:03 -0500

> DHCPv4 implementations might need tweaking.

As I said in my earlier email to Basavraj, DHCPv4 is one of the options among 
many e.g. IPCP (e.g. RFC 1877). The MIPv4 solution is lightweight and works w/o 
always setting up a reverse tunnel. It works w/o having to run another protocol 
and tweaking of DHCPv4 implementations in the mobility agents. It works for MNs 
that have no DHCPv4 capability.

-Kuntal

---

From: Kuntal Chowdhury <[email-masked]>
Date: Mon, 14 Jul 2003 09:24:55 -0500

> So why not pick one and only one way to do this?

There are already ways other than DHCP in place e.g. IPCP. Therefore "pick one 
and only one way" is a moot point. There are drawbacks of using IPCP, it does 
not work very well to get these configuration options from the home network.

The solution that was proposed in the MIPv4 extension draft works when the MN 
desires to get these config options from the home as well as the foreign network 
w/o having to run another protocol (DHCP/IPCP etc.)

Theoretically in MIPv4 we do IPv4 address configuration (home address) with 
MIPv4 messages. The draft that we proposed extends this config function in MIPv4 
to non-IPv4 config options.

---

From: Kuntal Chowdhury <[email-masked]>
Date: Mon, 14 Jul 2003 09:37:46 -0500

> result in their being two ways to get DNS addresses; DHCP and MIP.

Even w/o MIP we have atleast two ways i.e. IPCP and DHCP. I don't think it is 
ideal to say let's not work on new ways when there is already a way.

> for similar reasons to the ones I've brought up.)

Well, the draft that we proposed contains option for SIP proxy config as well. 
It also contains config options for Broadcast/Multicast controller that 3GPP2 
(may be 3GPP) is working on.

> Expediuous doesn't mean low cost over the lifetime of the solution.

Let the industry decide which one of the multiple ways will survive. Let's not 
restrict ourselves to one solution and hope it is the best we can ever get.

---

From: Mike Borella <[email-masked]>
Date: Mon, 14 Jul 2003 07:46:28 -0700 (PDT)

> Expediuous doesn't mean low cost over the lifetime
The crux of the issue is that when you have a method
of delivering IP addresses (and potentially other
configuration info) to a mobile, such as IPCP and MIP,
should you continue to extend those protocols to
support what you need or do you force the deployment
of DHCP, just to deliver configuration parameters and
not addresses.

The pros for DHCP is that you define all the
extensions in one place and don't have to modify IPCP
or MIP.  The cons are that it is more expensive
initially to deploy DHCP in a place where its not
needed, and you still end up with two solutions
because you have to manage a DHCP server in the home
network as well as an HA and a AAA.  

Taking a wild guess, I imagine that some operators
might prefer one way of doing things and others might
prefer the alternative.  However, each method
(IPCP/MIP vs DHCP) has its place.

Mike

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 14 Jul 2003 17:27:11 +0200 (CEST)

> As I said in my earlier email to Basavraj, DHCPv4 is one of the options
> among  many e.g. IPCP (e.g. RFC 1877). The MIPv4 solution is lightweight and
> works w/o  always setting up a reverse tunnel. It works w/o having to run
> another protocol  and tweaking of DHCPv4 implementations in the mobility
> agents. It works for MNs  that have no DHCPv4 capability.

Note that the pppext WG was asked about doing an RFC 1877 variant for IPv6
(RFC 1877 is informational) and the response is included below.
If you want more data on the "vociferous" aspect of the response you can
check the mailing list archive for the ietf-ppp mailing list.

Thus using the existence of the informational RFC 1877 as an argument
that adding DNS configuration information to MIP is not a good idea IMHO.

  Erik

>----------------Begin Forwarded Message----------------<

Date: 21 Jun 2003 08:02:47 -0400
From: "Karl Fox" <[email-masked]>
Subject: Two Drafts for PPP IPV6 Control Protocol Extensions
To: [email-masked]

I have determined that the consensus of this working group is that the
two Internet-Drafts,

   draft-ietf-pppext-ipv6-dns-addr-03.txt

and

   draft-ietf-pppext-ipv6-prefix-00.txt

not be considered for advancement as products of PPPEXT because they
duplicate methods better addressed by other, existing protocols.  Not
only this, but we will also object to the IESG if they are proposed as
individual, non-working-group submissions.

Historically, the people on this mailing list have been both vociferous
and consistent on this topic--use existing protocols to do the jobs for
which they were designed rather than duplicating their functions in PPP
for reasons related to their specific implementation or infrastructure.

>----------------End Forwarded Message----------------<

---

From: Kuntal Chowdhury <[email-masked]>
Date: Mon, 14 Jul 2003 10:51:47 -0500

Erik,

Today RFC 1877 is in use, so as DHCP. These two are not the only examples of 
similar things done in different ways in IETF. Another example is ROHC (RFC 
3095) and draft-ietf-avt-crtp-enhance-05.txt which is going to become an RFC soon.

Hence, the fact that some folks in PPPEXT do not like to work on a particular 
solution does not automatically apply to all work that are being done in IETF.

MIPv4 does provide IPv4 (home) address config option with RRQ/RRP. Therefore I 
don't understand why this function cannot be extended for non-IPv4 address 
config options?

-Kuntal

---

From: Alper Yegin <[email-masked]>
Date: Mon, 14 Jul 2003 11:41:19 -0700

> restrict ourselves to one solution and hope it is the best we can ever get.

Mobile IP protocol is for carrying IP-layer mobility signaling and related
information. It is not a generic host configuration protocol. So, carrying
any config information over this protocol is not justified. Saying but "we
are already doing Mobile IP" opens the door for carrying *any parameter*
over *any protocol that runs between the host and access network*. Does this
make sense? 

On the other hand, there might be some functional overlap between protocols
due to some historical or exceptional reasons. But I don't think this gives
us a free ticket to do whatever we like.

My 0.02 cents.

Alper

---

From: Kuntal Chowdhury <[email-masked]>
Date: Mon, 14 Jul 2003 14:27:28 -0500

> over *any protocol that runs between the host and access network*. Does this

Why not? look at AAA protocols used for dynamic server assignment, storing and 
retrieving anchor server addresses to name a few. Some of the routing protocols 
(OSPF for example) are used for label distribution for MPLS. Even MIP messages 
are going to used for key exchange as per some of WG drafts. Moreover, do you 
think the challenge response defined in RFC3012 is purely an IP-layer mobility 
issue?

---

From: Kent Leung <[email-masked]>
Date: Mon, 14 Jul 2003 12:44:21 -0700

I'd like to go back to the problem statement of the draft.

Requirement:  MN needs to know its home DNS server IP addresses when it is 
registered.
Everyone agree that this is needed.  Consensus, right?

One possible solution is to apply the DHCP draft to retrieve via DHCP 
Options.  But
some hurdles to that possibility:

         - MN doesn't have DHCP capability (PPP/IPCP only)
         - Home domain may not use DHCP for address allocation 
(alternatives such as AAA
           or local pool)

#1 - MNs that support PPP/IPCP only, use RFC 1877.  But this does not 
achieve the
objective of getting the DNS server info from the home domain since 
PPP/IPCP terminates
on the NAS/FA.

#2 - Not a technical issue, but changing how operators deploy their 
networks may be
futile.

So, back to attempting to resolve the requirement.  Is there an alternative 
solution to
getting the DNS server info to the MNs that can satisfy the hurdles?  I 
don't see any
in the opposition.  Though I believe we need a solution here.

Kent

At 10:51 AM 7/14/2003 -0500, Kuntal Chowdhury wrote:
>Erik,
>
>Today RFC 1877 is in use, so as DHCP. These two are not the only examples 
>of similar things done in different ways in IETF. Another example is ROHC 
>(RFC 3095) and draft-ietf-avt-crtp-enhance-05.txt which is going to become 
>an RFC soon.
>
>Hence, the fact that some folks in PPPEXT do not like to work on a 
>particular solution does not automatically apply to all work that are 
>being done in IETF.
>
>MIPv4 does provide IPv4 (home) address config option with RRQ/RRP. 
>Therefore I don't understand why this function cannot be extended for 
>non-IPv4 address config options?
>
>-Kuntal
>
>
>Erik Nordmark wrote:

---

From: Kuntal Chowdhury <[email-masked]>
Date: Mon, 14 Jul 2003 15:48:03 -0500

Kent,

Glad that you suggested to bring the discussion back into relevance here. Your 
analysis is good and it is inline with the motivation for writing the draft in 
the first place.

-Kuntal

Kent Leung wrote:
> Requirement:  MN needs to know its home DNS server IP addresses when it 
> is registered.
> So, back to attempting to resolve the requirement.  Is there an 
> alternative solution to
>> Today RFC 1877 is in use, so as DHCP. These two are not the only 
>> examples of similar things done in different ways in IETF. Another 
>> example is ROHC (RFC 3095) and draft-ietf-avt-crtp-enhance-05.txt 
>> which is going to become an RFC soon.
>>

---

From: Alper Yegin <[email-masked]>
Date: Wed, 16 Jul 2003 08:45:42 -0700

> Why not? 

A super-optimized solution for your "own architecture" does not necessarily
mean it is the right solution for IETF, which aims developing protocols for
the "Internet architecture." I don't mean to sound too philisophical, but
this is just difference in priorities.

> look at AAA protocols used for dynamic server assignment, storing and

My general response is: just because it is done does not mean that it can be
done all across the board. And I'm sure there would be existing cases that I
would disagree. Otherwise:
- I think AAA servers have the concept of profiles. I don't know if there
are guidelines for what goes in those profile, what not.
- No idea about the OSPF-MPLS case.
- challenge-response is a replay protection technique for the protocol
signaling. Questioning its usage with Mobile IP is akin to questioning a MIC
field in a protocol.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Wed, 16 Jul 2003 08:52:13 -0700

Hi Kent,

> (alternatives such as AAA

These constraints must be a particular architecture's constraints, not
general IETF protocol suite constraint. I think this is the core source of
difference in opinions.

> objective of getting the DNS server info from the home domain since

I don't fully know which architecture we are solving this for, but if there
is authentication and AAA involved:
- PPP authentication (or MIPv4 auth), in conjunction with Radius/DIAMETER,
could bring in the DNS parameter to NAS. If NAS implements DHCP Relay or
Agent, it  can deliver this parameter to the host.

Alper

---

From: Kent Leung <[email-masked]>
Date: Wed, 16 Jul 2003 14:48:15 -0700

Hi Alper.

>general IETF protocol suite constraint. I think this is the core source of

I would agree with you from the purist perspective.  Though I'm not sure
if the world is that ideal.  Else we would probably be running ATM, or
IPv6, or OSI.  :)  And using meters instead of yards.  I'm getting off the
issue..  but I think we still have to handle what we have been dealt.  See
possible alternative to solving the problem below.

>Agent, it  can deliver this parameter to the host.

As you probably already know, there is no PPP authentication for Mobile IP
service in 3GPP2.  And the reality is that not all operators want to use DHCP.

> > in the opposition.  Though I believe we need a solution here.

If you are saying that this is not a generic Mobile IP issue but 
3GPP2-centric.  And
that it's better to update IS-835 to add 3GPP2 VSA for these functions, I'm 
not sure
if I would completely disagree.  However, GPRS would have the same problem when
PPP is not used.  3GPP may also encounter this issue, depending on how that
L2 authentication is specified.

Kent