Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt(SECOND REQUEST)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt(SECOND REQUEST)
Alpesh,
The problem is not implementation specific. The reason 3344 doesn't
talk about these things is becasue it doesn't have to. 3344 doesn't at
all deal with how the clietn is configured, it's just a pre-requsite.
Note that this is specifically normal behaviour and 3344 is written to
support it (well, atleast it supports it).
The reason why this becomes an issue here is that this is the first time
ever (as far as I know) that a MN has been configured with a HA
information in a Registration request extension. Thus, this have to
support both the case where the MN have a CoA (the external address) and
the case where the MN is in the home network (the internal).
The meere phrases internal and external address might however be new to
some people and at first sight be thought of as oimplementation
specific. But still, some mechanism is needed. Using the extension is one.
/// Hasse
Alpesh wrote:
Henrik -
Isn't this issue implementation specific? RFC3344 does not talk about
HA with multiple interfaces too.
I was wondering if such an implementation can specify one or more
private addresses using a VSE?
How does the MN currently come to know the private address?
-a
Henrik Levkowetz wrote:
Hello Yoshi,
The case Hans describes is not the HA behind NAT case, it is just
one where the HA is accessible through more than one interface. You
could have this setup:
..... Internet .... ........ Home Link .........
. . .
. +----+ +-------+ .
. | | | MN | .
.<=========>| HA |<---------->|3.4.5.9| .
. 3.4.5.1 | |3.4.5.254 +-------+ .
. +----+ .
. . .
............................
In this case, there is no NAT, but you would still need to know both the
address of the HA on your home link, and the public address of the HA. I
know that not all HAs out there is designed to be positioned in this
manner, and I also believe that some support other ways of identifying
the HA's home link interface, rather than explicitly listing it (or
them). But all HAs are definitely not so simple that they can be fully
described (assigned) through a single address.
I don't know if 2 addresses are enough, or if we need to be able to
supply a list of addresses, or even a list of address/mask pairs,
though.
Henrik
Friday 13 February 2004, Yoshiyuki Tsuda wrote:
Hello Hans,
Your comment is interesting, but it isn't directly related to
dynamic HA, but rather related to NAT traversal in case of
an HA sitting behind NAT, I'm afraid. So, we had better
discuss about your issue as an improvement of the current
NAT traversal RFC, or a separate draft.
I think, if you can describe that your issue has more close
relation to dynamic HA, rather than NAT traversal, it will
help the authers to answer to you.
Cheers.
-Yoshi
at Thu, 12 Feb 2004 16:50:44 +0100 Hans Sjöstrand wrote:
Sorry for being late with my comment,
I think the proposal is a good proposal. And so does a few of my
customers who has asked for the functionality. To bad that they didn't
flag their interest on the list.
However, there is one thing that I think is needed to be added to the
draft to make the function usable. The extension carries to little
information.
Normally a router or gateway with HA functionality have several
interfaces. The natural setup is that the gateway is accessible to
internet on one interface (or address) and have the HA advertising the
home network on another network. In many cases the home network have a
private address space.
The MN needs to know two things,
1) The address which I can reach my home agent from internet (the
"external address").,
2) The address which my home agent is advertising on the home network
(the "internal address").
In the case with dynamic home agent assignment, the MN is informed about
the assigned "external address", but he is totally unaware of the
"internal address". Subsequently the MN will never be able to recognise
when he has entered his home network. Therefore this information needs
to be relayed to him. Preferably in the Redirected HA address extension
which then would look something like
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent External Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Internal Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home Agent External Address The IP address that the home agent is externally
reachable. This might be a IP address on the Home
agent or a IP address of an external device that
will redirect or map the IP packets to the home agent.
Home Agent Internal Address The IP address of the home agent. This might be the
same address as the Home Agent External Address or an
address on an internal network. This address MUST be
the same address that the Home agent uses for the
Mobility Agent Advertisements.
Best regards
/// Hasse
Henrik Levkowetz wrote:
SECOND REQUEST - To date, no response to this WG last call has been
received. If enough responses are not received to support the
acceptance of this document, it *will not* be submitted to the IESG for
publication. Please respond to this WG last call. If you support
acceptance of the document without change, respond with a simple
acknowledgment, so that support for the document can be assessed.
--------
This message announces a WG last call on "Mobile IPv4 Dynamic Home Agent
Assignment" <draft-ietf-mip4-dynamic-assignment-00.txt>. The last call
will conclude at 24:00 UTC on Friday, 13th Feb 2004.
Please respond to this WG last call. If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.
draft-ietf-mip4-dynamic-assignment-00.txt proposes a messaging mechanism
for dynamic home agent assignment and HA redirection. The goal is to
provide a mechanism to assign an optimal HA for a Mobile IP session
while allowing any suitable method for HA selection.
This draft is available as
<http://www.ietf.org/internet-drafts/draft-ietf-mip4-dynamic-assignment-00.txt>
Regards,
Henrik
--
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/mailman/listinfo/mip4
--
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/mailman/listinfo/mip4
--
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/mailman/listinfo/mip4
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
