Subject: [Pana] [pana-ipsec] PAC-LINK-LOCAL in IPv4

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 21 Jan 2004 11:39:15 -0800

In section 6 of pana-ipsec draft:

"        IPv4/IPv6 header (source = PAC-LINK-LOCAL,
                           destination = EP-LINK-LOCAL)
         ESP header
         IPv4/IPv6 header (source = PAC-GLOBAL-ADDR,
                           destination = END-ADDR)
                                                                                
   Following is the packet format on the wire for packets sent from EP
   to PaC:

         IPv4/IPv6 header (source = EP-LINK-LOCAL,
                           destination = PAC-LINK-LOCAL)
         ESP header
         IPv4/IPv6 header (source = END-ADDR,
                           destination = PAC-GLOBAL-ADDR)"

I am not sure what PAC-LINK-LOCAL means in the case of IPv4.  Does it
mean IPv4 link-local address specified in
draft-ietf-zeroconf-ipv4-linklocal?  If so, the IPv4 link-local draft
explcitly says:

   "This
   document does not recommend that Link-Local IPv4 addresses and
   routable addresses be configured simultaneously on the same
   interface."

and I think PAC-GLOBAL-ADDR should be used instead of PAC-LINK-LOCAL
in the case of IPv4.

Regards,
Yoshihiro Ohba

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

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 21 Jan 2004 13:07:11 -0800

> draft-ietf-zeroconf-ipv4-linklocal?  If so, the IPv4 link-local draft
Yes, that's what i meant.

> and I think PAC-GLOBAL-ADDR should be used instead of PAC-LINK-LOCAL
I agree with this. Most of the current implementations use only one of them. You
try to configure a global and if you don't get one, try the link-local. 

I will modify the draft accordingly for IPv4 drafts.

thanks
-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 21 Jan 2004 13:07:11 -0800

thanks
-mohan

---

From: Alper Yegin <[email-masked]>
Date: Wed, 21 Jan 2004 17:31:11 -0800

>  routable addresses be configured simultaneously on the same

I don't think it should be a problem to use the link-local address as the
tunnel end point, and the global address inside the tunnel. I don't think
this is what the zeroconf draft is prohibiting.

Nevertheless, we can consider using the same global IP address as the tunnel
end point and as the inner IP address as soon as the PaC gets one. Any pros
and cons here?

Alper

---

From: Alper Yegin <[email-masked]>
Date: Wed, 21 Jan 2004 17:31:11 -0800

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 21 Jan 2004 18:38:23 -0800

> this is what the zeroconf draft is prohibiting.

OK, I see what you mean.

> end point and as the inner IP address as soon as the PaC gets one. Any pros

At least Windows 2000 and XP implementations, link-local address is
available only after performing DHCP and the DHCP has been failed.  It
takes long time (about 30 seconds in my measurement) until DHCP fails,
which is unacceptable.  In the same implementations, if DHCP succeeds,
link-local address is not available as Mohan mentioned.  An advantage
would be that only one stateful configuration protocol operation is
needed for obtaining the inner addres.

On the other hand, if we use global IP address as the outer address,
unauthenticated DHCP would be performed to obtain a pre-PANA address.
In an environment where the post-PANA address (i.e, the global
address) is assigned to authenticated clients only, the pre-PANA and
post-PANA addresses will be different.  This means that two stateful
configuration protocol operations will be needed, one for pre-PANA
address and the other for the post-PANA address.  But this is much
better than waiting for lengty DHCP timeout to configure an IPv4
link-local address.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 21 Jan 2004 18:38:23 -0800

OK, I see what you mean.

Yoshihiro Ohba

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 22 Jan 2004 09:40:45 -0800

> needed for obtaining the inner addres.
One of the reasons we started using link-local address in PANA is to stay
compatible with what the majority of the clients do today as you described
above. There may be an advantage,  but the deployment may not allow
it e.g. where address is assigned from your ISP only after authentication.

> better than waiting for lengty DHCP timeout to configure an IPv4
I agree with this. 30 second delay might be too much. And this does not need
any change in the behavior of the existing clients. So, i assume that
the pre-pana address can be a RFC1918 private address. What should
be the lease time for the pre-pana address i.e what should be recommended ?
If you want to tunnel all packets using the pre-pana address (for the outer),
 then it makes sense to keep the lifetime of both the addresses same.
Addresses might time out independently but it should not cause any problems
 i guess. If we recommend a very small lease time for the pre-pana address,
 then we should use the post-pana address for both inner and outer address. 
I know of some implementations that has problem with this (tunnel module
drops the packets destined to the outer address itself as it thinks there is
a routing loop). But as we have only PANA protocol packets destined to
EP/PAA itself, we can setup a bypass rule for this in the SPD.

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 22 Jan 2004 09:40:45 -0800

-mohan

---

From: Alper Yegin <[email-masked]>
Date: Thu, 22 Jan 2004 12:19:29 -0800

> it e.g. where address is assigned from your ISP only after authentication.

As normal, the IPv4 host would attempt DHCP. If it fails, it will fall back
to link-local addresses. So, before the PANA run, the host will have one of
these:
1- a link-local IPv4 address (using zeroconf)
2- a DHCP address that it will also use for data communication later
3- a DHCP address that is only used during PANA
4- a DHCP address that is used during PANA, and also as the tunnel end point
later

After PANA, the client will attempt getting another IPv4 address depending
on the information in the PANA bind message. Only case 2 above does not
require another IP address acqusition.

The same PANA bind message will also imply whether the current IP address
should be unconfigured prior to configuring the new one. If IPsec tunneling
is used, the pre-PANA address will be maintained as the tunnel end point.
Otherwise, the pre-PANA address will be released, and post-PANA address will
be configured.

So now, if case (1) is followed by getting a global IPv4 address via DHCP
after PANA exchange, and IPsec is used, what should be used in the tunnel
outer header? Unless we rebind the DI to the new IP address, the link-local
address would be the answer.

> the pre-pana address can be a RFC1918 private address.

Yes, even if it is configured via DHCP, it can be a RFC1918 address.

> What should

I think using a short lease does not require that we use post-PANA address
for both inner and outer headers. A longer lease can be granted when the
current one expires.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 22 Jan 2004 12:19:29 -0800

Alper

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 22 Jan 2004 16:09:57 -0800

> address would be the answer.
First, clarification regarding re-bind. When IPsec is used, the SA is bound to the
post-pana address. Who is benefiting from rebinding the DI to the new IP address i.e
why is it needed in the IPsec case ?

Now, whether we want to use one address or two addresses on an interface ?
We have to understand whether there are source address selection issues
with any of the implementation or not. We have a default route to EP through
an interface with 2 addresses on it. Both the address are /32. Normally
the source address is picked from the outgoing interface if the application
has not initialized it. If each of the address is configured as a separate logical
interface, then it may not have problems. Otherwise, not sure what address will
be picked for packets trying to reach off-link. You don't want the link-local
address.

> for both inner and outer headers. A longer lease can be granted when the

Sure. Has anyone tried configuring e.g. linux, two addresses using DHCP on
a interface ? I don't know how easy or cumbersome it is.

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 22 Jan 2004 16:09:57 -0800

-mohan

---

From: Alper Yegin <[email-masked]>
Date: Thu, 22 Jan 2004 18:25:31 -0800

> why is it needed in the IPsec case ?

At least for network management and accounting reasons, we sould make sure
the PANA state and the data traffic in the network is consistent. I think
this is achieved only when the PaC DI appears on the data packets (whether
its an IP address or MAC address). So, I think, if we are going to use
post-PANA address on the tunnel header we should register it as PaC DI.

Otherwise, I guess you are suggesting a discrepancy between the DI sent from
PAA to EP and the tunnel headers doesn't break IKE and IPsec processing.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 22 Jan 2004 18:25:31 -0800

Alper