![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Alpesh,
In addition to Hans' comments, it bears mentioning that rfc3344 in
several places clearly discusses both FAs and HAs having multiple
interfaces. Explicitly limiting the dynamic HA assgnment mechanism
to work with only the one-interface case seems wrong.
Henrik
Thursday 12 February 2004, 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
> >>
> >>
> >
> >
> >
>
>
Attachment:
pgp00086.pgp
Description: PGP signature