Subject: Re: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt

From: "John.zhao" <[email-masked]>
Date: Mon, 14 May 2007 01:05:14 +0800

Hi,Sangjin Jeong

    Right. That should be considered as a abnormal situation.So the problem is if we still need to provide the IP address and host information to that kind of MN when it enter into rebinding state. 
	Because to an abnormal situation, it seems that we even can discard the following rebind message too.Because the rebinding should only provide someone that should enjoy this service. For some emergence or out-of-scope reason. Our system didn't need to provide something any more.
	My two cents.
	
			Best Rgds,
Thanks,

	　　　　　　　　John.zhao

　　	　	　　　　　[email-masked]
　　　	　	　　　　　　2007-05-14
======= 2007-05-11 21:31:00 You have said:=======

>Hi John,
>
>Thanks for your kind explanation.
>See inline, please.
>
>On 5/11/07, John.zhao <[email-masked]> wrote:
>> Hi,Sangjin
>>
>>        OK. I see you described the basic idea. So something can be appended
>> based on that.
>>        What I means about the home network is referred to the network that
>> LMA located. Because all of the traffics towards to or comes from MN will
>> via the tunnel between MAG and LMA.
>
>OK. I see.
>
>>        So that problem I mean is that if the server-id isn't equal to any
>> one of old MAG and new MAG? Why? Error handler or is a normal case? If error
>> handler , then discard is no problem.
>
>In the scenario where LMA assigns IPv4 HoA, MN should get its HoA from MAG
>through DHCP procedures. Further, MAG is seen as DHCP server from MN.
>So, the server-id should indicate MAG's address. If the server-id in
>MN is neither
>old MAG nor new MAG's address during handover, it will imply that MN gets
>its HoA from other means or has configuration error. In any case, it does
>not seem to be normal behavior. Thus, discarding the DHCP message is more
>reasonable, IMO.
>
>Regards,
>Sangjin
>
>> But if is a normal case, it should be
>> transferred simply. And to a PMIP MN, it only has the reverse tunnel can be
>> chosen.
>>        My two cents.
>>
>>        Best Rgds,
>> Thanks.
>>
>> John.zhao
>>
>> -----邮件原件-----
>> 发件人: Sangjin Jeong [mailto:[email-masked]]
>> 发送时间: 2007年5月11日 15:11
>> 收件人: [email-masked]
>> 抄送: RYUJI WAKIKAWA; [email-masked]; [email-masked]
>> 主题: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt
>>
>> Hi John,
>>
>> I briefly described just the basic idea. :)
>>
>> On 5/11/07, John.zhao <[email-masked]> wrote:
>> > Hi,Sangjin
>> >
>> >        I think this description can work. But for avoiding to cause some
>> > confusion. The new MAG can check the server-id option in unicast DHCP
>> > request any more. Typically, there are three scenarios existed in this
>> > message:
>> >        1)The server-id option contain a IP address that is equal to the
>> new
>> > MAG address. Then that means the new MAG should handle this DHCP message
>> > directly.
>> >        2)The server-id option contain a IP address that isn't equal to the
>> > new MAG address but it equal to the previous MAG(if the new MAG can know
>> the
>> > old MAG ip address stored in MN). Then this message should be discarded to
>> > force the MN enter into rebinding state.
>> >        3)The server-id option contain a IP address that is equal to
>> neither
>> > the new MAG address , nor the old MAG address. How do dealt with them?
>> > Simple discarded? Or reverse tunnel to home network?
>>
>> Would you elaborate on this? What kind of home network do you mean?
>>
>> Regards,
>> Sangjin
>>
>> > I think seems the later
>> > is the right choice to keep some normal behavior can continue.
>> >        My two cents.
>> >
>> > Best Rgds,
>> > Thanks,
>> > John.zhao
>> >
>> > -----邮件原件-----
>> > 发件人: Sangjin Jeong [mailto:[email-masked]]
>> > 发送时间: 2007年5月11日 13:37
>> > 收件人: RYUJI WAKIKAWA
>> > 抄送: [email-masked]; [email-masked]; [email-masked]
>> > 主题: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt
>> >
>> > Hi Ryuji,
>> >
>> > On 5/11/07, RYUJI WAKIKAWA <[email-masked]> wrote:
>> > > Hi John and Sangjin,
>> > >
>> > > On 2007/05/11, at 11:24, John.zhao wrote:
>> > >
>> > > > Hi, Domagoj and sangjin
>> > > >
>> > > >          Based on the rebind method, I think some necessary
>> > > > parameter will be share between new MAG and old MAG to confirm the
>> > > > right reassignment and avoid some possible attack.
>> > > >
>> > > >          As to the DHCP Server stay w/o LMA schema, I think that
>> > > > seems not very feasible.
>> > > >
>> > > >          That DHCP Force Renew signal is a good way, but if the new
>> > > > MAG send it ,then why the client can believe that. I think RFC3203
>> > > > didn't metion about it.
>> > >
>> > > Good point. The force-renew message can be possible security
>> > > vulnerability.
>> > > It is better that the MN should go into the REBINDING state and
>> > > broadcast DHCPREQ again.
>> >
>> > Let me summarize this issue.
>> >
>> > - When MAG sends DHCP offer to MN, MAG's IP address will be
>> > included in the server-id option.
>> > - MAG discards MN's unicast DHCP request whose destination
>> > is not the MAG itself so that the MN can go into DHCP REBINDING
>> > state and broadcast DHCP request without server-id.
>> >
>> > Any thoughts?
>> >
>> > Regards,
>> > Sangjin
>> >
>> > >
>> > > regards,
>> > > ryuji
>> > >
>> > > >
>> > > >
>> > > > Best Rgds,
>> > > >
>> > > > Thanks,
>> > > >
>> > > > John.zhao
>> > > >
>> > > > ------------------------------
>> > > >
>> > > > Date: Thu, 10 May 2007 17:24:37 +0200
>> > > >
>> > > > From: "Premec, Domagoj" <[email-masked]>
>> > > >
>> > > > Subject: RE: [netlmm] I-D
>> > > >
>> > > >          ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt
>> > > >
>> > > > To: "Sangjin Jeong" <[email-masked]>
>> > > >
>> > > > Cc: Ryuji Wakikawa <[email-masked]>, [email-masked]
>> > > >
>> > > > Message-ID:
>> > > >
>> > > >
>> > > > <[email-masked]>
>> > > >
>> > > > Content-Type: text/plain;   charset="iso-8859-1"
>> > > >
>> > > >
>> > > >
>> > > > Hi Sangjin,
>> > > >
>> > > >
>> > > >
>> > > > > > We could also let the MAG act as a DHCP relay and the LMA
>> > > >
>> > > > > as DHCP server. Then it would be the LMA's address in the server-id
>> > > >
>> > > > > option. In other words, DHCP messaging from the first figure in your
>> > > >
>> > > > > mail would be extended all the way to the LMA. This approach has no
>> > > >
>> > > > > issues with handover.
>> > > >
>> > > > > >
>> > > >
>> > > > >
>> > > >
>> > > > > The v4 support draft describes three address assignment schemes,
>> > > >
>> > > > > static, dynamic with LMA, and dynamic with DHCP server. When DHCP
>> > > >
>> > > > > server is used for assigning IPv4 home address, there will be DHCP
>> > > >
>> > > > > relay agent on the link and it will relay the DHCP messages to DHCP
>> > > >
>> > > > > server. As you said, there is no issue in this case.
>> > > >
>> > > > >
>> > > >
>> > > > > However, when LMA assigns home address, there is no DHCP server or
>> > > >
>> > > > > relay agent. What I am considering is this case.
>> > > >
>> > > >
>> > > >
>> > > > Yes, I see. I guess I was assuming that DHCP server and the LMA are
>> > > > collocated in the same box.
>> > > >
>> > > >
>> > > >
>> > > > If they are not, and if the lease time expires, how does the LMA
>> > > > learn about expired address? DHCP server may even assign the
>> > > > expired address to another host. IMO, the LMA (and MAG) should stop
>> > > > providing service to the host if its address expired.
>> > > >
>> > > >
>> > > >
>> > > > I see several options:
>> > > >
>> > > > - DHCP server and LMA communicate by means which are out of scope
>> > > > of this spec (not really helpfull)
>> > > >
>> > > > - we let the MAG monitor the lease time and deregister with LMA if
>> > > > it expires
>> > > >
>> > > > - or maybe we can somehow couple the lease time and the MIP binding
>> > > > lifetime
>> > > >
>> > > >
>> > > >
>> > > > > > Another solution could be to let the client go into
>> > > >
>> > > > > rebinding state. Then the client would broadcast the DHCP-REQ which
>> > > >
>> > > > > would contain the client's current IP address and would not contain
>> > > >
>> > > > > the server-id option. The new MAG would respond with DHCP-ACK
>> > > >
>> > > > > extending the lease time of the currently assigned IP address.
>> > > > And the
>> > > >
>> > > > > response would contain the address of the new MAG in the server-id
>> > > >
>> > > > > option.
>> > > >
>> > > > > >
>> > > >
>> > > > >
>> > > >
>> > > > > Yes right. I proposed that scheme to Ryuji during initial
>> > > > discussion.
>> > > >
>> > > > > However, I prefer to force the client to renew its state quickly. :)
>> > > >
>> > > >
>> > > >
>> > > > Maybe we could keep both options. I think not many clients today
>> > > > implement DHCP-FORCERENEW. If the client doesn't support
>> > > > FORCERENEW, it will end up in rebinding state, so the MAG should be
>> > > > able to handle this situation.
>> > > >
>> > > >
>> > > >
>> > > > regards
>> > > >
>> > > > domagoj
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > > -----Original Message-----
>> > > >
>> > > > > From: Sangjin Jeong [mailto:[email-masked]]
>> > > >
>> > > > > Sent: 10. svibanj 2007 13:33
>> > > >
>> > > > > To: Premec, Domagoj
>> > > >
>> > > > > Cc: Ryuji Wakikawa; [email-masked]
>> > > >
>> > > > > Subject: Re: [netlmm] I-D
>> > > >
>> > > > > ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt
>> > > >
>> > > > >
>> > > >
>> > > > > Hi Domagoj,
>> > > >
>> > > > >
>> > > >
>> > > > > See inline please.
>> > > >
>> > > > >
>> > > >
>> > > > > On 5/10/07, Premec, Domagoj <[email-masked]> wrote:
>> > > >
>> > > > > > Hi Sangjin,
>> > > >
>> > > > > >
>> > > >
>> > > > > > > Since LMA assigns MN's home network address and there is no DHCP
>> > > >
>> > > > > > > server, MAG should use its IP address as the server-id so
>> > > >
>> > > > > that MAG
>> > > >
>> > > > > > > can respond MN's DHCP messages.
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > MAG may use LMA address as the server-id. However, if MAG
>> > > >
>> > > > > informs MN
>> > > >
>> > > > > > > of LMA address as a server address, MN will send DHCP
>> > > > messages to
>> > > >
>> > > > > > > LMA address and MAG will have to intercept them.
>> > > >
>> > > > > > > IMHO, it is not a natural way for MAG to intercept/respond DHCP
>> > > >
>> > > > > > > unicast messages whose destination address is not itself.
>> > > >
>> > > > > > > Additionally, since MAG performs DHCP server-side function,
>> > > >
>> > > > > > > specifying MAG's address in DHCP message seems to be more
>> > > >
>> > > > > reasonable.
>> > > >
>> > > > > >
>> > > >
>> > > > > > We could also let the MAG act as a DHCP relay and the LMA
>> > > >
>> > > > > as DHCP server. Then it would be the LMA's address in the server-id
>> > > >
>> > > > > option. In other words, DHCP messaging from the first figure in your
>> > > >
>> > > > > mail would be extended all the way to the LMA. This approach has no
>> > > >
>> > > > > issues with handover.
>> > > >
>> > > > > >
>> > > >
>> > > > >
>> > > >
>> > > > > The v4 support draft describes three address assignment schemes,
>> > > >
>> > > > > static, dynamic with LMA, and dynamic with DHCP server. When DHCP
>> > > >
>> > > > > server is used for assigning IPv4 home address, there will be DHCP
>> > > >
>> > > > > relay agent on the link and it will relay the DHCP messages to DHCP
>> > > >
>> > > > > server. As you said, there is no issue in this case.
>> > > >
>> > > > >
>> > > >
>> > > > > However, when LMA assigns home address, there is no DHCP server or
>> > > >
>> > > > > relay agent. What I am considering is this case.
>> > > >
>> > > > >
>> > > >
>> > > > > > > Also, if MAG's address is used as the server-id, there is
>> > > > another
>> > > >
>> > > > > > > issue related to MN's handover.
>> > > >
>> > > > > >
>> > > >
>> > > > > > Another solution could be to let the client go into
>> > > >
>> > > > > rebinding state. Then the client would broadcast the DHCP-REQ which
>> > > >
>> > > > > would contain the client's current IP address and would not contain
>> > > >
>> > > > > the server-id option. The new MAG would respond with DHCP-ACK
>> > > >
>> > > > > extending the lease time of the currently assigned IP address.
>> > > > And the
>> > > >
>> > > > > response would contain the address of the new MAG in the server-id
>> > > >
>> > > > > option.
>> > > >
>> > > > > >
>> > > >
>> > > > >
>> > > >
>> > > > > Yes right. I proposed that scheme to Ryuji during initial
>> > > > discussion.
>> > > >
>> > > > > However, I prefer to force the client to renew its state quickly. :)
>> > > >
>> > > > >
>> > > >
>> > > > > Regards,
>> > > >
>> > > > > Sangjin
>> > > >
>> > > > >
>> > > >
>> > > > > > regards
>> > > >
>> > > > > > domagoj
>> > > >
>> > > > > >
>> > > >
>> > > > > >
>> > > >
>> > > > > >
>> > > >
>> > > > > > > -----Original Message-----
>> > > >
>> > > > > > > From: Sangjin Jeong [mailto:[email-masked]]
>> > > >
>> > > > > > > Sent: 09. svibanj 2007 11:20
>> > > >
>> > > > > > > To: Ryuji Wakikawa
>> > > >
>> > > > > > > Cc: [email-masked]
>> > > >
>> > > > > > > Subject: Re: [netlmm] I-D
>> > > >
>> > > > > > > ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > Hi Ryuji,
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > Thanks for developing IPv4 support document.
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > There is a concern when MAG performs DHCP server functionality.
>> > > >
>> > > > > > > Actually, it was raised during initial version discussion, so I
>> > > >
>> > > > > > > bring it back.
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > According to the v4 support document, the following
>> > > >
>> > > > > procedures will
>> > > >
>> > > > > > > be performed when LMA assigns IPv4 HoA.
>> > > >
>> > > > > > >
>> > > >
>> > > > > > >  MN      MAG      LMA
>> > > >
>> > > > > > >   |------>|        |    1. DHCP discovery
>> > > >
>> > > > > > >   |       |------->|    2. Proxy Binding Update
>> > > >
>> > > > > > >   |       |<-------|    3. Proxy Binding Ack (IPv4HoA)
>> > > >
>> > > > > > >   |       |========|    4. Tunnel/Route Setup*
>> > > >
>> > > > > > >   |<------|        |    5. DHCP offer (IPv4 HoA)
>> > > >
>> > > > > > >   |------>|        |    6. DHCP request (IPv4 HoA)
>> > > >
>> > > > > > >   |<------|        |    7. DHCP acknowledgement
>> > > >
>> > > > > > >   |       |        |
>> > > >
>> > > > > > > * Tunnel/Route setup(no.4) and DHCP offer/request/ack(no.5-7)
>> > > >
>> > > > > > >   are processed in parallel.
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > In Step 5, DHCP offer will include server-id in the
>> > > >
>> > > > > message and DHCP
>> > > >
>> > > > > > > clients will use the IP address provided in the server-id for
>> > > > any
>> > > >
>> > > > > > > unicast requests to the DHCP server.
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > Since LMA assigns MN's home network address and there is no DHCP
>> > > >
>> > > > > > > server, MAG should use its IP address as the server-id so
>> > > >
>> > > > > that MAG
>> > > >
>> > > > > > > can respond MN's DHCP messages.
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > MAG may use LMA address as the server-id. However, if MAG
>> > > >
>> > > > > informs MN
>> > > >
>> > > > > > > of LMA address as a server address, MN will send DHCP
>> > > > messages to
>> > > >
>> > > > > > > LMA address and MAG will have to intercept them.
>> > > >
>> > > > > > > IMHO, it is not a natural way for MAG to intercept/respond DHCP
>> > > >
>> > > > > > > unicast messages whose destination address is not itself.
>> > > >
>> > > > > > > Additionally, since MAG performs DHCP server-side function,
>> > > >
>> > > > > > > specifying MAG's address in DHCP message seems to be more
>> > > >
>> > > > > reasonable.
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > IMHO, it is necessary to add following requirement in Step 5.
>> > > >
>> > > > > > > "MAG uses its IP address as the server identifier in DHCP offer"
>> > > >
>> > > > > > >
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > Also, if MAG's address is used as the server-id, there is
>> > > > another
>> > > >
>> > > > > > > issue related to MN's handover.
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > Refer to the following figure, please.
>> > > >
>> > > > > > > Let's assume a MN moved from old MAG (oMAG) to new MAG (nMAG)
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > MN     oMAG    nMAG      LMA
>> > > >
>> > > > > > >  |-------|------>|        |    1. MN attachment
>> > > >
>> > > > > > >  |       |       |------->|    2. Proxy Binding Update
>> > > >
>> > > > > > >  |       |       |<-------|    3. Proxy Binding Ack (IPv4HoA)
>> > > >
>> > > > > > >  |       |       |========|    4. Tunnel Setup
>> > > >
>> > > > > > >  .       .       .        .
>> > > >
>> > > > > > >  |------>|       |        |    5. DHCP request (renew)
>> > > >
>> > > > > > >  |       |       |        |
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > Since the MN does not know the link change, the DHCP
>> > > >
>> > > > > client in the
>> > > >
>> > > > > > > MN will unicast DHCP request (renew) to the server IP
>> > > >
>> > > > > address which
>> > > >
>> > > > > > > was acquired by oMAG (server-id). This might be
>> > > >
>> > > > > undesirable behavior
>> > > >
>> > > > > > > because oMAG maintains state for the MN that is not in the
>> > > > access
>> > > >
>> > > > > > > link anymore. Thus, DHCP client in the MN needs to
>> > > >
>> > > > > reconfigure its
>> > > >
>> > > > > > > local configuration parameters. One simple solution would be to
>> > > >
>> > > > > > > force the DHCP client to renew its state by sending DHCP
>> > > >
>> > > > > FORCERENEW
>> > > >
>> > > > > > > message as follows.
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > MN     oMAG    nMAG      LMA
>> > > >
>> > > > > > >  |-------|------>|        |    1. MN attachment
>> > > >
>> > > > > > >  |       |       |------->|    2. Proxy Binding Update
>> > > >
>> > > > > > >  |       |       |<-------|    3. Proxy Binding Ack (IPv4HoA)
>> > > >
>> > > > > > >  |       |       |========|    4. Tunnel Setup
>> > > >
>> > > > > > >  |<------|-------|        |    5. DHCP FORCERENEW*
>> > > >
>> > > > > > >  |       |       |        |
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > * nMAG sends DHCP FORCERENEW to MN.
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > Regards,
>> > > >
>> > > > > > > Sangjin
>> > > >
>> > > > > > >
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > ----- Original Message -----
>> > > >
>> > > > > > > From: <[email-masked]>
>> > > >
>> > > > > > > To: <[email-masked]>
>> > > >
>> > > > > > > Cc: <[email-masked]>
>> > > >
>> > > > > > > Sent: Friday, April 27, 2007 4:50 AM
>> > > >
>> > > > > > > Subject: [netlmm] I-D
>> > > >
>> > > > > > > ACTION:draft-ietf-netlmm-pmip6-ipv4-support-00.txt
>> > > >
>> > > > > > >
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > >A New Internet-Draft is available from the on-line
>> > > >
>> > > > > Internet-Drafts
>> > > >
>> > > > > > > >directories.
>> > > >
>> > > > > > > > This draft is a work item of the Network-based Localized
>> > > >
>> > > > > > > Mobility Management Working Group of the IETF.
>> > > >
>> > > > > > > >
>> > > >
>> > > > > > > > Title : IPv4 Support for Proxy Mobile IPv6
>> > > >
>> > > > > > > > Author(s) : R. Wakikawa, S. Gundavelli Filename :
>> > > >
>> > > > > > > > draft-ietf-netlmm-pmip6-ipv4-support-00.txt
>> > > >
>> > > > > > > > Pages : 25
>> > > >
>> > > > > > > > Date : 2007-4-26
>> > > >
>> > > > > > > >
>> > > >
>> > > > > > > >   This document specifies extensions to the Proxy Mobile
>> > > >
>> > > > > > > IPv6 protocol
>> > > >
>> > > > > > > >   [ID-PMIP6] for supporting IPv4.  The scope of the
>> > > >
>> > > > > IPv4 support in
>> > > >
>> > > > > > > >   Proxy Mobile IPv6 includes the support for the mobile
>> > > >
>> > > > > node's IPv4
>> > > >
>> > > > > > > >   home address mobility and for supporting the scenario
>> > > >
>> > > > > > > where the local
>> > > >
>> > > > > > > >   mobility anchor and the mobile access gateway are
>> > > >
>> > > > > separated by an
>> > > >
>> > > > > > > >   IPv4 transport network.  The solution primarily leverages
>> > > > the
>> > > >
>> > > > > > > >   extensions defined in Dual Stack Mobile IPv6
>> > > >
>> > > > > specification [ID-
>> > > >
>> > > > > > > >   DSMIP6] for achieving this.
>> > > >
>> > > > > > > >
>> > > >
>> > > > > > > >
>> > > >
>> > > > > > > > A URL for this Internet-Draft is:
>> > > >
>> > > > > > > >
>> > > >
>> > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-netlmm-pmip6-ip
>> > > >
>> > > > > > > v4-support-00.txt
>> > > >
>> > > > > > > >
>> > > >
>> > > > > > > > To remove yourself from the I-D Announcement list, send a
>> > > >
>> > > > > > > message to
>> > > >
>> > > > > > > > [email-masked] with the word unsubscribe in
>> > > >
>> > > > > > > the body of
>> > > >
>> > > > > > > > the message.
>> > > >
>> > > > > > > > You can also visit
>> > > >
>> > > > > > > https://www1.ietf.org/mailman/listinfo/I-D-announce
>> > > >
>> > > > > > > > to change your subscription settings.
>> > > >
>> > > > > > > >
>> > > >
>> > > > > > > > Internet-Drafts are also available by anonymous FTP. Login
>> > > > with
>> > > >
>> > > > > > > > the username "anonymous" and a password of your e-mail
>> > > > address.
>> > > >
>> > > > > > > > After logging in, type "cd internet-drafts" and then "get
>> > > >
>> > > > > > > > draft-ietf-netlmm-pmip6-ipv4-support-00.txt".
>> > > >
>> > > > > > > >
>> > > >
>> > > > > > > > A list of Internet-Drafts directories can be found in
>> > > >
>> > > > > > > > http://www.ietf.org/shadow.html or
>> > > >
>> > > > > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> > > >
>> > > > > > > >
>> > > >
>> > > > > > > > Internet-Drafts can also be obtained by e-mail.
>> > > >
>> > > > > > > >
>> > > >
>> > > > > > > > Send a message to:
>> > > >
>> > > > > > > > [email-masked].
>> > > >
>> > > > > > > > In the body type:
>> > > >
>> > > > > > > > "FILE
>> > > >
>> > > > > /internet-drafts/draft-ietf-netlmm-pmip6-ipv4-support-00.txt".
>> > > >
>> > > > > > > >
>> > > >
>> > > > > > > > NOTE: The mail server at ietf.org can return the document in
>> > > >
>> > > > > > > > MIME-encoded form by using the "mpack" utility.  To use this
>> > > >
>> > > > > > > > feature, insert the command "ENCODING mime" before the "FILE"
>> > > >
>> > > > > > > > command.  To decode the response(s), you will need
>> > > >
>> > > > > "munpack" or a
>> > > >
>> > > > > > > > MIME-compliant mail reader.  Different MIME-compliant
>> > > >
>> > > > > mail readers
>> > > >
>> > > > > > > > exhibit different behavior, especially when dealing with
>> > > >
>> > > > > > > > "multipart" MIME messages (i.e. documents which have
>> > > >
>> > > > > been split up
>> > > >
>> > > > > > > > into multiple messages), so check your local
>> > > >
>> > > > > documentation on how
>> > > >
>> > > > > > > > to manipulate these messages.
>> > > >
>> > > > > > > >
>> > > >
>> > > > > > > > Below is the data which will enable a MIME compliant
>> > > >
>> > > > > mail reader
>> > > >
>> > > > > > > > implementation to automatically retrieve the ASCII
>> > > >
>> > > > > version of the
>> > > >
>> > > > > > > > Internet-Draft.
>> > > >
>> > > > > > > >
>> > > >
>> > > > > > >
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > --------------------------------------------------------------
>> > > >
>> > > > > > > ------------------
>> > > >
>> > > > > > >
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > > _______________________________________________
>> > > >
>> > > > > > > > netlmm mailing list
>> > > >
>> > > > > > > > [email-masked]
>> > > >
>> > > > > > > > https://www1.ietf.org/mailman/listinfo/netlmm
>> > > >
>> > > > > > > >
>> > > >
>> > > > > > >
>> > > >
>> > > > > >
>> > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > netlmm mailing list
>> > > > [email-masked]
>> > > > https://www1.ietf.org/mailman/listinfo/netlmm
>> > >
>> > >
>> >
>> >
>> >
>>
>>
>>

= = = = = = = = = = = = = = = = = = = =

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