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,
After thinking about your proposal I start to lean towards your proposal
using a VSE for this purpose.
There are several advantages in not incorporating anything else than the
redirected HA address in the extension exactly as you originally proposed.
Because what I really, really want is not an address, it's a way to
identify my home agent. and when the NAI draft is published, I can do
that a lot better with a NAI in the HA adverticement rather than a
internal address. It woulds be bad in this case if we lock in the
dynamic HA assignment in an old-school limited solution.
With a separate configuration extension we also get the freedom that the
additional configuration very well might take place in the registration
withe the assigned HA, not neccesarily in the first routndtrip with teh
requested HA.
Also, there are more goodies that I would like to transfer to the MN,
which indeed are implementation specific, so maybe I'll use a VSE anyway.
Thanks for the comments and sorry for stirring up dust.
A few smaller comments though
1. The extension is a little odd. In most other IETF protocools (atleast
the ones I've been in) tries to maintain 4 byte alignment. It would be
nice if the extension looked like this instead.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redirected-HA-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2. I'm not terribly happy about the described behavior for the unicast address case. In the proposed scheme it's impossible for the HA (or HA cluster or whatever) to actually know if the MN will accept and/or support a redirect. This may very well result in that a client without support for dynamic HA assignments gets unneccassary rejects from the HA's even though it's perfectly ok to register.
To solve this, one way would be to mandate the MN always to send the extension if the dynamic HA assignment is supported and configured. Another way is to remove the option to have a unicast address in the HA field. I didn't quite understand the advantage over just always use ALL-ZERO-ONE-ADDR.
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.
