Subject: [Mip6] Issue 71: Avoid configuration at the HA about port forwarder

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 12 Oct 2006 05:01:17 -0700

Issue description:
------------------

When a HA is placed within a private network, the HA must enforce UDP
encapsulation whether or not the MN/MR owns a public address.

The draft does not enable the HA to discover that situation; implicitly,
there
must be some configuration in the HA to let it know that it is behind a
NAT, so
that the HA sends a NAT detection option.

Configuration is a hassle for customers, and it is error prone:
- There is a way to automate the NAT discovery and remove the manual
configuration
- There is also a way to make it symmetrical, so that both ends reach a
same
conclusion without the need to introduce an additional NAT detection
option

If we decide to automate the discovery of the reverse NAT (== port
forwarder)
then we might consider two alternatives:

option 1) Extends what is already done in 4.1 with the mapped address,
by
modifying the format of the mapped address to include all the needed
parameters
(IP and ports). This is what the doors proposal suggests, in order to
leave most
of the HA code and data structures unchanged. 

option 2) add an option in the BU and BA where the sender exposes the IP
addresses and port as he sees them. 

A discrepancy can be found on the receiver and interpreted as a presence
of a
NAT box on the way.

The drawback of the automation is that it can not detect a transparent
device
such as a load balancer placed in front of a cluster of HAs. This might
not be a
big issue if there is an optional config to force the UDP at all times,
which
should be there anyway to enable faster roaming.

Issue analysis
--------------
The issue suggests adding an automated mechanism to the draft to allow
the HA to discover that it is located in a private IPv4 domain (i.e.
behind the NAT). The issue correctly describes the current assumption in
the draft that the HA is configured with such knowledge. Regardless of
whether this issue is accepted or rejected, this assumption must be
clarified in the draft. 

In principle, (i.e. focussing on the technical requirement in this
issue) I don't recall a strong objection. However, there were several
concerns raised about the scenario described in this issue and some
non-technical issues described below:

- Concerns against the scenario: Some concerns were raised about the
importance of the scenario described above. Generally speaking, it is
expected that HAs are manually configured with several parameters like
security paramaters and mapping them to allocated addresses. Therefore,
if configuration has to be done manually anyway, why is this particular
parameter a problem? One answer to this question is that network
conditions may change resulting in the HA being behind a NAT. In this
case other configuration parameters would not change, but this
particular parameter will need to be added. 

Another concern about the reality of this scenario is related to the
difficulty of allocating a public address to the HA. Some people did not
agree that IPv4 addresses would be so scarce. However, such concern is
clearly difficult to verify one way or another as it is very specific to
the deployment scenario. 

- IPR concerns: We were made aware of the existence of IPR that may well
cover potential solutions to this issue. This has raised concerns in the
DT about whether a solution to this issue should be handled in the base
spec or done later as an optional add-on. 

Conclusion
----------

There was no clear concensus in the DT one way or another, altough more
people were in favour of rejecting this issue than those who were
willing to accept it. 
Please provide input on this issue. The options we have are either :

1. Accept issue: This does not imply any particular solution, it simply
means that this issue is worth solving in the base spec. 

2. Reject issue: This means that this issue is not worth solving in the
base spec. Of course it can be done later in a different doc but this is
outside the scope of this discussion.

Folks, please give some reasons for accepting or rejecting because I
have a feeling that the rationale might be helpful here in order to
break the tie. 

Hesham

Conclusion
-----------

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Oct 2006 15:10:13 +0200

Thanks for the description.

I think rejecting the issue is a good choice - don't treat about HA
behind NAT, keep the DS-MIPv6 spec simpler.

MIP deployments seem to favour MN-together-with-HA in same
administrative domain (no NAT between HA and MN), or otherwise HA with a
publicly routable address (no HA behind NAT, but MN behind NAT).

If we talk HA behind NAT then there are two possibilities, not just one:
either there is port forwarder on HA's NAT, or there is a RDV point on
the publicly routable Internet, that both  MN and HA contact to
detect their positions.  For a complete NAT solution one would have to
design both the detection with port forwarder and detection with a RDV
point.

(the need of having an IPv4 publicly routable address for HA is moot if
we separate the IPv6-only HA from the NAT that may be in front of it.
But this separation is impossible by current DS-MIPv6 design, which
forces HA to run both IPv4 and IPv6.)

Alex

Soliman, Hesham wrote:
> Issue description: ------------------
> 
> The draft does not enable the HA to discover that situation; 
> implicitly, there must be some configuration in the HA to let it know
>  that it is behind a NAT, so that the HA sends a NAT detection 
> option.
> 
> 
> Configuration is a hassle for customers, and it is error prone: - 
> There is a way to automate the NAT discovery and remove the manual 
> configuration - There is also a way to make it symmetrical, so that 
> both ends reach a same conclusion without the need to introduce an 
> additional NAT detection option
> 
> forwarder) then we might consider two alternatives:
> 
> option 1) Extends what is already done in 4.1 with the mapped 
> address, by modifying the format of the mapped address to include all
>  the needed parameters (IP and ports). This is what the doors 
> proposal suggests, in order to leave most of the HA code and data 
> structures unchanged.
> 
> option 2) add an option in the BU and BA where the sender exposes the
>  IP addresses and port as he sees them.
> 
> A discrepancy can be found on the receiver and interpreted as a 
> presence of a NAT box on the way.
> 
> The drawback of the automation is that it can not detect a 
> transparent device such as a load balancer placed in front of a 
> cluster of HAs. This might not be a big issue if there is an optional
>  config to force the UDP at all times, which should be there anyway 
> to enable faster roaming.
> 
> Issue analysis -------------- The issue suggests adding an automated 
> mechanism to the draft to allow the HA to discover that it is located
> in a private IPv4 domain (i.e. behind the NAT). The issue correctly
> describes the current assumption in the draft that the HA is
> configured with such knowledge. Regardless of whether this issue is
> accepted or rejected, this assumption must be clarified in the draft.
> 
> 
> 
> 
>  importance of the scenario described above. Generally speaking, it
> is expected that HAs are manually configured with several parameters
>  like security paramaters and mapping them to allocated addresses. 
> Therefore, if configuration has to be done manually anyway, why is 
> this particular parameter a problem? One answer to this question is 
> that network conditions may change resulting in the HA being behind a
>  NAT. In this case other configuration parameters would not change, 
> but this particular parameter will need to be added.
> 
>  difficulty of allocating a public address to the HA. Some people did
>  not agree that IPv4 addresses would be so scarce. However, such 
> concern is clearly difficult to verify one way or another as it is 
> very specific to the deployment scenario.
> 
> - IPR concerns: We were made aware of the existence of IPR that may 
> well cover potential solutions to this issue. This has raised 
> concerns in the DT about whether a solution to this issue should be 
> handled in the base spec or done later as an optional add-on.
> 
> Conclusion ----------
> 
> There was no clear concensus in the DT one way or another, altough 
> more people were in favour of rejecting this issue than those who 
> were willing to accept it. Please provide input on this issue. The 
> options we have are either :
> 
> 1. Accept issue: This does not imply any particular solution, it 
> simply means that this issue is worth solving in the base spec.
> 
> 2. Reject issue: This means that this issue is not worth solving in 
> the base spec. Of course it can be done later in a different doc but 
> this is outside the scope of this discussion.
> 
> Conclusion -----------
> _______________________________________________ Mip6 mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/mip6
>

---

From: "James Kempf" <[email-masked]>
Date: Thu, 12 Oct 2006 10:22:28 -0700

I agree that the issue should be rejected. HAs are in managed networks, so I 
believe one can make the reasonable assumption that they can be configured 
to properly do NAT traversal.

            jak

----- Original Message ----- 
From: "Soliman, Hesham" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, October 12, 2006 5:01 AM
Subject: [Mip6] Issue 71: Avoid configuration at the HA about port forwarder

Issue description:
------------------

Issue analysis
--------------

Conclusion
----------

Hesham

Conclusion
-----------

---

From: "Tsirtsis, George" <[email-masked]>
Date: Thu, 12 Oct 2006 11:04:12 -0700

I second that. Although IPv4 addresses are a limited resource, it seems
that it is not unreasonable to require one public IPv4 address for the
operation of an HA that will service a large numbers of mobiles (all of
which can happily be using private IPv4 addresses). Manual port-mappings
can also be used for smaller deployments (e.g., home networks)

In any case, if and when that becomes a problem for someone, an
appropriate mechanism can be defined at that time.

George

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Thursday, October 12, 2006 1:22 PM
> To: Soliman, Hesham; [email-masked]
> Subject: Re: [Mip6] Issue 71: Avoid configuration at the HA about
> portforwarder
> 
> I agree that the issue should be rejected. HAs are in managed
networks, so
> I
implicitly,
> option 2) add an option in the BU and BA where the sender exposes the
IP
> A discrepancy can be found on the receiver and interpreted as a
presence
> should be there anyway to enable faster roaming.
not
> - IPR concerns: We were made aware of the existence of IPR that may
well
> spec or done later as an optional add-on.
more
> 1. Accept issue: This does not imply any particular solution, it
simply
> 2. Reject issue: This means that this issue is not worth solving in
the

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 12 Oct 2006 11:10:32 -0700

James Kempf wrote:
> I agree that the issue should be rejected. HAs are in managed networks, 
> so I believe one can make the reasonable assumption that they can be 
> configured to properly do NAT traversal.

+1

Vijay

> 
>            jak
> 
> ----- Original Message ----- From: "Soliman, Hesham" 
> <[email-masked]>
> To: <[email-masked]>