headers
Ville Nuorvala | 1 Sep 2004 13:36
Picon
Picon

Aggregated prefixes and Proxy ND

Hi,

while reading draft-ietf-nemo-basic-support-pre04.txt I started wondering
about how the HA actually should perform Proxy ND on behalf of the MR.

The thing is of course straight forward if the MR's HoA is from a prefix
advertised on the home link, but it all gets a bit complicated if it's
from a prefix that the MR advertises on its ingress interface.

Since the HoA will never be on the same link as the HA, should the HA
still do the DAD probe and perform Proxy ND for it? Then again, I guess
there isn't any harm in doing that, so perhaps it's ok for the HA to
always do Proxy ND for the MR.

Regards,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval <at> tcs.hut.fi, phone: +358 (0)9 451 5257
Permalink | Reply | 2 comments |
headers
Mazen TLAIS | 1 Sep 2004 16:32
Picon
Favicon

Re: new draft

 --- Mattias Pettersson
<mattias.l.pettersson <at> ericsson.com> a écrit : 
> 
> 
> Mazen TLAIS wrote:
> > Hi Mattias,
> > 
> > Here are some responses for your comments
> > 
> > 
> >>You seem to assume that there is a suitable point
> in
> >>a typical access 
> >>network where an ARC can be placed. From your
> draft
> >>I can't be sure what 
> >>security relationships that are required, but if
> the
> >>ARC needs security 
> >>relationships with many ARs this in general
> creates
> >>scalability 
> >>problems.
> > 
> > Updating messages sent by MR to ARC need 
> > security relationships. I'm not sure about ARs.
> > 
> > 
> > 
> >>My general assumption is that in order to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mattias Pettersson | 1 Sep 2004 18:46
Picon
Favicon

Re: Aggregated prefixes and Proxy ND


Ville Nuorvala wrote:
> Hi,
> 
> while reading draft-ietf-nemo-basic-support-pre04.txt I started
> wondering
> about how the HA actually should perform Proxy ND on behalf of the MR.
> 
> The thing is of course straight forward if the MR's HoA is from a prefix
> advertised on the home link, but it all gets a bit complicated if it's
> from a prefix that the MR advertises on its ingress interface.
> 
> Since the HoA will never be on the same link as the HA, should the HA
> still do the DAD probe and perform Proxy ND for it? Then again, I guess
> there isn't any harm in doing that, so perhaps it's ok for the HA to
> always do Proxy ND for the MR.

If the MR's HoA is derived from the MNP, it does not belong to the home 
link, and no node attached on the home link will ever assume it is 
on-link, thus never do ND address resolution for it.

An implementation of IPv6/ND shouldn't even allow ND proxying for 
off-link prefixes.

This is my interpretation.

/Mattias
Permalink | Reply | 0 comments |
headers
Alexandru Petrescu | 1 Sep 2004 20:50

Re: Aggregated prefixes and Proxy ND

Ville Nuorvala wrote:
> while reading draft-ietf-nemo-basic-support-pre04.txt I started 
> wondering about how the HA actually should perform Proxy ND on behalf
>  of the MR.
> 
> The thing is of course straight forward if the MR's HoA is from a 
> prefix advertised on the home link, but it all gets a bit complicated
>  if it's from a prefix that the MR advertises on its ingress 
> interface.

I agree.

> Since the HoA will never be on the same link as the HA, should the HA
>  still do the DAD probe and perform Proxy ND for it?

My personal view is no.  But there may be particular cases where it's
yes.  Co-authors may help clarify; reasons I remember relate to RO, like 
"RO is easier if HoA from ingress".

You may want to find a usually used thing that overstretches or breaks
when HA does proxy ND and DAD for the HoA of the ingress.  If you find
it, state it here and see...  For example, I don't know...

Alex
Permalink | Reply | 0 comments |
headers
Pascal Thubert (pthubert | 2 Sep 2004 14:05
Picon
Favicon

RE: new draft

Hi Mazen:

I believe that it is pretty natural for a Mobile Router to own more than
one egress interface. Typically today, you'll find MRs with a modem and
a 802.11 interfaces.

It is also expected that you'll find some proprietary logic for a MR to
select its interface and its AR over that interface. Sometimes, it's as
obvious as: .11 is fast and free, modem is slow and expensive... guess
what, modem has a lower priority then WIFI.

On the other hand, potential ARs may be on a same (or same type of)
egress interface, but they might provide uneven services (nesting level,
security, bandwidth). I would really like to see a draft that examines
that problem and makes recommendations on how MRs should behave, what
should be customizable in the AR selection, etc... if you're interested
:)

For current implementations or trials, a set of tools are available:

RFC 2461: RA is the base tool for all. Proves to be a little slow for
mobility

RFC 3775: improves ND making RA faster and more verbose.

DNA: should go further in NUD but still, the AR is the horizon.  

draft-ietf-ipv6-router-selection-05.txt helps the node (the MR in our
case) select its attachment router based on a preference, and routes if
you are lucky enough to find an AR that has a more specific route to
(Continue reading)

Permalink | Reply | 501 comments |
headers
Nicolas Montavont | 2 Sep 2004 11:51
Picon
Picon
Favicon

Re: Question on TD

Hi all,

Sorry for the late reply...

I don't think we should remove the multihoming case in the draft.
If we agree that we need new option(s) to discover and build trees,
it is also important to forward useful information to MNNs for their 
configuration.

As you point out, in a nested NEMO, several encapsulations might be needed.
So, if we could forward the MR's level in RAs, this information may help 
the MNNs to choose their default router, before configuring anything 
(MNNs establishes L2 link and then began the level 3 configuration).

My point here is to consider the nested NEMO issue in its globality: how 
to avoid loops, how to build the trees, how to recover from a failure, 
how to optimize the route selection and so on.

Nicolas

Masafumi Watari wrote:

>Hi all,
>
>On Tue, 31 Aug 2004 14:24:20 +0200,
>"Pascal Thubert (pthubert)" <pthubert <at> cisco.com> wrote:
>
>  
>
>>I agree that the multihoming case in the draft may not be the most appropriate and we might remove it for
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pascal Thubert (pthubert | 2 Sep 2004 15:08
Picon
Favicon

RE: Aggregated prefixes and Proxy ND

Hi Ville :)

> Since the HoA will never be on the same link as the HA, should the HA
> still do the DAD probe and perform Proxy ND for it? Then again, I
guess
> there isn't any harm in doing that, so perhaps it's ok for the HA to
> always do Proxy ND for the MR.

I'm not sure that the nemo basic support spec should say anything about
that; but the home network model, definitely, because this depends no
the model being deployed.

NEMO has extended the MIP concept of Home. Depending on the model, Home
might be applied on a virtual or a physical link. Or Home might just be
an aggregation that is declared to the HA configuration in terms of
routes. What is supported depends on the implementation. If Home is not
applied on a physical link, then obviously there is no DAD.

Conceptually, there is a movement out of ND dependencies. MIP6 is based
on ND, NEMO has remnants of that when the home link is applied on a
physical link, HAHA protocol gets rid of that completely.

In fine, the idea is that the home address would end up being used as a
unique ID, and NEMO could a route to the MNP over a tunnel that ends at
the Care-Of Address, the whole thing being correlated by the home
address. The fact that the home address is on a home link, on an MNP, or
just any form of unique ID would be inconsequential.

But for now with nemo basic support: the Home Addresses being part of
the MNPs is not a problem is the link is virtual or if Home is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mazen TLAIS | 2 Sep 2004 20:17
Picon
Favicon

RE: new draft


 --- "Pascal Thubert (pthubert)" <pthubert <at> cisco.com>
a écrit : 
> Hi Mazen:
> 
> I believe that it is pretty natural for a Mobile
> Router to own more than
> one egress interface. Typically today, you'll find
> MRs with a modem and
> a 802.11 interfaces.
> 
> It is also expected that you'll find some
> proprietary logic for a MR to
> select its interface and its AR over that interface.
> Sometimes, it's as
> obvious as: .11 is fast and free, modem is slow and
> expensive... guess
> what, modem has a lower priority then WIFI.
> 
> On the other hand, potential ARs may be on a same
> (or same type of)
> egress interface, but they might provide uneven
> services (nesting level,
> security, bandwidth). I would really like to see a
> draft that examines
> that problem and makes recommendations on how MRs
> should behave, what
> should be customizable in the AR selection, etc...
> if you're interested
> :)
(Continue reading)

Permalink | Reply | 501 comments |
headers
Carlos Jesús Bernardos Cano | 14 Sep 2004 15:52
Picon

IETF60 NEMO minutes

Hi all,

	Are the minutes from last IETF NEMO meeting available?

	Thanks a lot.

	Carlos J.

--

-- 
Carlos Jesús Bernardos Cano - http://www.it.uc3m.es/cjbc/
GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40
Permalink | Reply | 0 comments |
headers
Alexandru Petrescu | 16 Sep 2004 14:38

list admin stuff: when subscribing use a meaningful email address

Hi all,

I'm addressing this message to all potential new subscribers to the NEMO
mailing list (this list), but not to the existing subscribers.

When subscribing to the NEMO list, please use a meaningful email address
that reflects somehow your identity.  Email addresses containing first
name and/or last name are the ideal choices.  Also, good choices may
contain the string "nemo" or "ietf" or "software" or "protocol" or
"hacking" or similar in the name part.  Even "temple of saint nemo"
sounds good.

Very bad choices are constituted by some apparently random strings, such
as "xnpqmcnf <at> expanets.com" or "xqdjjxyzz <at> knology.net" or other strings
usually generated by mass UCE such as "thirdman77 <at> yahoo.co.jp" or
"pacificlotto2004 <at> yahoo.com".

I'm continuously banning subscription of such bad email addresses, on a
first come first served basis; but I never ban subscriptions of
meaningful addresses, such as "jennifer <at> eyou.com".

In case of problem subscribing to the NEMO list, please write to
nemo-admin <at> ietf.org, Chairs and myself are aliased to it.

Thanks,

Alex
Permalink | Reply | 0 comments |

Gmane