Subject: Move forward

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 11 Mar 2003 19:36:08 +0100 (CET)

Let me offer an opinion on how we can move forward.

As I see it, there are basically four classess of IPv6 multihoming
solutions that have any promise:

1. "No changes" routing-based approaches, ranging from simple (ignore
   the scalability problem for now) to complex (geo aggregation).

2. Weak identifier/locator separation: the identifier is an address
   usable for routing that is replaced/hidden in transit in some way,
   typically by a router or middlebox (MHAP, but also
   tunneling/redirection mechanisms)

3. Strong identifier/locator separation: the identifer isn't an address
   usable for routing, so the end host must implement the solution
   (basic multiaddressing as we know it today, SCTP, HIP)

4. Mobility-based approaches (although this could be classified under 2.)

If we can make an upgrade path from type 1 solutions to type 2
solutions and from type 2 solutions to type 3 solutions, this will
greatly enhance the prospects of each. Also, it should be much, much
easier to draw up good requirements for each type of solution rather
than the generic "we want it all but it can't cost anything" type of
requirements we have now.

With those requirements in hand we can apply the "people who say
something can't be done shouldn't get in the way of the people doing it"
rule.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 11 Mar 2003 19:59:13 +0100

> solutions and from type 2 solutions to type 3 solutions, this will

I think this is a very good approach and also what I tried to start 
doing with the road-map, except that I tried to group all solutions, 
and only noted the need to create a path forward. Do you think it would 
be useful to extend this document with this (or create a new one?). I 
don't mind changing the classes if we can consensus on a common 
grouping of approaches?

> something can't be done shouldn't get in the way of the people doing 

Well said.

- kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 11 Mar 2003 20:23:07 +0100 (CET)

> don't mind changing the classes if we can consensus on a common

I think this way of classifying solutions can be very useful when trying
to come up with requirements or creating desing teams. However, in a
document that introduces someone to the subject this grouping may seem
arbitrary.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 12 Mar 2003 08:11:02 +0859 ()

Iljitsch;

> greatly enhance the prospects of each.

No.

>    tunneling/redirection mechanisms)

The proble is that there is no such solutions.

If you disagree, feel free to use type 1 and 2 solutions with IPv4.

>    (basic multiaddressing as we know it today, SCTP, HIP)

Here is the point where the merit of having longer address could be
deployed.

A point of multi6 is that we can do it from the beginning.

> something can't be done shouldn't get in the way of the people doing it"

You are getting in the way of the people doing type 2 and 3 insisting
that there should be upgrade path from type 1 and 2.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Mar 2003 00:52:08 +0100 (CET)

> No.

If we want to do something with PI in type 1, that's going to be hard
because it doesn't scale well enough in the long run. If we want to do 2
at all there's the problem that everyone has to implement it before it
works. However, if we first do 1 and then 2 people who want 2 will use 1
as long as 2 isn't available yet (so more use for 1) and people don't
have to be afraid 1 will blow up in their faces because they're
migrating to 2 later. So both are more viable.

> The proble is that there is no such solutions.

There are drafts. Don't know if they solve anything...

But the point is that we work on it. It seems likely that any existing
draft or proposal can be improved upon if we work together. You wouldn't
know it, but there are actually some very smart people in multi6.  :-)

> If you disagree, feel free to use type 1 and 2 solutions with IPv4.

GFN isn't going to work to any usable degree with IPv4 because there
simply aren't enough bits. There are many other type 1-like solutions in
actual use in v4, though. Type 2 could work well if you don't mind
burning two or three times as many addresses.

> Here is the point where the merit of having longer address could be

Actually this type of solution doesn't really need the bigger addresses.
I would even like to have type 3 run over both v4 and v6.

> that there should be upgrade path from type 1 and 2.

Since anything that can be done in a middlebox can also be done in a
host, the upgrade path from 2 to 3 shouldn't limit 2 too much.
Essentially, 2 is a subset of 3. As for 1 to 2: I think the burden
should be mostly on 1 there. More concrete: I want to use PI addresses
in a type 1 solution that become the identifiers in a type 2 solution. A
type 2 solution could also use PA addresses but that would be stupid as
PI is much better for the user and there aren't many down sides to using
PI in type 2. There are in type 1 so we should see if we can afford it
there.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 12 Mar 2003 09:31:14 +0859 ()

Iljitsch;

> Essentially, 2 is a subset of 3.

You are saying your classification is meaningless.

We can move forward a little if you admit that, by definition,
weak separation is not a subset of strong separation.

The hard part, then, is to define what are "weak" and "strong".

> If we want to do 2
> works.

Remember that my 8+8 with doubtlessly-strong separation is
interoperating with leagacy IPv6 stack that it can be deployed
gradually. That is, we can move forward without wasting time
to define what is "weak".

The problem of deploying type 1 is that it will bloat global routing
table unnecessarily, which can not be restored later.

Note that, in an RIR, some says routing table must grow unmanageably
large.

> But the point is that we work on it.

We should "move forward", not "work on moving backward".

							Masataka Ohta

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Mar 2003 09:24:24 +0200 (EET)

> 4. Mobility-based approaches (although this could be classified under 2.)

This is ignoring the short-term solutions with multiple addresses.

I'm not sure what you refer to with mobility based approaches.  It seems
to me that such do not exist (which would help with multihoming, that is).

I'll be probably submitting a draft on my "big picture" in April or so.  

At the moment it looks like we don't have all that much work to do in the
short term..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Mar 2003 10:56:48 +0100 (CET)

> You are saying your classification is meaningless.

No, I'm pretty much sure you're saying this. But then I firmly believe
that everything is meaningless except for the meaning we choose to
bestow upon any particular thing. If you find my my classification
meaningless that's ok, I'll use it as long as it suits my needs.

> The hard part, then, is to define what are "weak" and "strong".

Feel free to suggest better names for the classes.

> gradually.

??? How?

> table unnecessarily, which can not be restored later.

My point is that this isn't necessarily the case: if we start giving out
PI space that is simply allowed in the global routing table, we have
bloat. But if at some point a type 2 solution becomes available, we can
simply start moving in the middleboxes and after a suitable transition
period the PI /48s can be removed from the global routing table because
the middleboxes translate all the traffic. It should be possible to do
this in a way that is transparent to end hosts.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Mar 2003 11:01:31 +0100 (CET)

> This is ignoring the short-term solutions with multiple addresses.

No, these are type 3. Note that they fail to meet some basic multihoming
requirements, though, so they shouldn't be considered viable solutions
as-is, except for some specific application types such as the DNS.

> to me that such do not exist (which would help with multihoming, that is).

Agree. The overlap with mobility has been observed many times, but
little progress so far in this area.

> At the moment it looks like we don't have all that much work to do in the

Obviously writing drafts hasn't helped to move things forward so far. So
I want to build some proof of concept stuff. That's plenty of short term
work.  :-)

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Mar 2003 12:15:18 +0200 (EET)

On Wed, 12 Mar 2003, Iljitsch van Beijnum wrote:
> No, these are type 3. 

Well, not by the classification: there is no strong identifier/locator
separation in e.g. host-centric multihoming approach.

> Note that they fail to meet some basic multihoming

Which realistic solutions _do_ meet those requirements?

Right..
 
> little progress so far in this area.

Mobility could be useful, IMO, if and only if you could secure a construct
like Binding Update with like, IPsec.  And this is a non-starter at the
moment.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Mar 2003 11:30:45 +0100 (CET)

> separation in e.g. host-centric multihoming approach.

Well, let's not start a flame war over this. If we're going to have a
few more classes then it would make sense to make this a separate class.

But my reasoning is that those solutions really use an implicit
locator/identifier separation: an email domain has several MXes. The
email domain is the identifier, the MX addresses are the locators. SCTP
doesn't even seem to use an identifier at all, so I guess the socket or
control block is the identifier there. It's certainly not any of the
individual addresses. And this must be done on the host so it's the
"strong" variety.

> Right..

Address agile TCP, to name just one?

> like Binding Update with like, IPsec.  And this is a non-starter at the

IPsec isn't as evil as people think it is. I got it to work in a few
hours. As long as we can have the IPsec just between the mobile host and
the home agent this shouldn't really be a show stopper.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Mar 2003 12:49:07 +0200 (EET)

> Address agile TCP, to name just one?

Some folks might not agree on its reality.

Besides, how can you manage e.g. inbound loadbalancing/traffic engineering
with that?  I think that was one of those "we want everything"
requirements.
 
> the home agent this shouldn't really be a show stopper.

No, this is not enough.  Such a model just shifts the problem around so 
that we'd require "truly multihomed" home agents.  IMO, that's not a 
solution.

On the other hand, if global PKI existed and was usable, one could perform
"homeless mobility".  Node X with addresses X_1 and X_2 (from different
ISP's) could just signal to the other endpoint that the sessions should
continue using the other address.  But this authentication is not possible
today.  In fact, if you take a few more steps in this direction, you'll
stumble upon HIP.

---

From: Marcelo Bagnulo <[email-masked]>
Date: Wed, 12 Mar 2003 12:05:29 +0100

Hi Pekka, Iljitsch

> that we'd require "truly multihomed" home agents.  IMO, that's not a 

We have tried to evaluate a concrete proposal for multi-homing using 
MIPv6 tools. The result can be found:

http://www.ietf.org/internet-drafts/draft-bagnulo-multi6-mnm-00.txt

We would really appreciate your comments,

Thanks, marcelo

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 13 Mar 2003 02:23:21 +0859 ()

Iljitsch;

> meaningless that's ok, I'll use it as long as it suits my needs.

For a classification suits some need, classes of the classification,
by definition, MUST be mutually disjoint.

That is, your need is nonsense even in an abstract sense.

> Feel free to suggest better names for the classes.

I suggested not to have the classes, which actually are not classes
at all.

> > interoperating with leagacy IPv6 stack that it can be deployed

As I wrote to Brian, reserve some bit(s) to designate address
families and use legacy upper layers unless both source and
destination addresses are of the new ones.

It is implemented and is interoperating with the legacy stack.

> bloat.

That is enough to argue against 6bonebof.

> But if at some point a type 2 solution becomes available, we can

If ever the type 1 is deployed to some extent, people using it won't
accept any proposal which require them additionally purchase the
middleboxes.

Wheter it is transparent to end hosts or not is irrelevant.

Proposals requiring middleboxes at some transition stage is
definitely not deployable.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 13 Mar 2003 02:37:48 +0859 ()

Pekka;

> to me that such do not exist (which would help with multihoming, that is).

There is no approaches based on MIPv6.

Mobile protocol with a single home agent (or something like that)
is unreliable and useless.

That is, to make multihoming useful, it should be without any single
point of failure and have multiple home agents.

Then, such mobile protocols solve most, or all, of the problems of
multihoming.

However, the classification for type 4 is not productive, as all the
useful solutions are, in a sense, mobility based.

							Masataka Ohta

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Mar 2003 19:56:15 +0200 (EET)

> useful solutions are, in a sense, mobility based.

These "mobile protocols" you refer to are locator/identifier separation
variants, like HIP or LIN6, I assume.

I agree with them as long term approaches, but I'm not sure about the
classification of all the useful solutions under "mobility".  Mobility is
too vague a word for that.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 12 Mar 2003 20:33:02 +0100

> document that introduces someone to the subject this grouping may seem

Agreed. But if you are referring to the road-map document, that was not 
meant to be an introduction to the subject.

- kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 13 Mar 2003 08:05:11 +0859 ()

Pekka;

> variants, like HIP or LIN6, I assume.

No. All.

> classification of all the useful solutions under "mobility".

I can't see any reason to have short and long term approaches.

All we need is a solution and a solution-specific transition strategy.

Some solution may require two steps of transition. But, such a
solution is poor with complex and painful transition and should
be avoided.

> Mobility is too vague a word for that.

That is a problem of the original classification attempt.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 15 Mar 2003 21:08:05 +0100 (CET)

> We would really appreciate your comments,

Ok, some comments:

- It looks like you want to authenticate the secondary address
  beforehand when there is still return routability. But can you then
  simply keep the secndary address in some kind of "hot standby" state
  untill it is time to start using it and then use it for some
  considerable amount of time without re-authentication? Does this work
  and is it secure? Oh wait: "This is a major limitation for this
  application, since the binding can not be refreshed until the original
  route is restored and outages can last longer than 420 seconds."

- ICMP echo for keepalive wouldn't work. Not so much because of all the
  broken firewalls that block them, but because the only thing an echo
  reply tells you is that there is _someone_ present at the address, it
  doesn't tell you who it is. (Ie dial user may have logged out and
  another logged in and gotten the same address.)

- Why don't you look at the return traffic to see if the path is still
  viable? If you keep (re)sending data but there is no reply from the
  other side, something must be broken. This probably needs per-session
  state, though.

- "If a failure   has occurred along the path, the attempt to initiate
  the communication will fail and the CN will try again with another
  address. Eventually, a packet from CN will reach MHH." As this is
  application-dependent you can't count on this. Worse: the all-time
  most popular networked application typically chokes if the first address
  tried doesn't work.

- Having to interact every 70 seconds may break sessions that would
  otherwise remain intact. For instance, I often put my laptop to sleep
  in the middle of a session to conserve the battery. When it wakes up,
  my session is still ok because there was no communication during the
  nap so the fact that my laptop was effecitvely disconnected didn't
  matter. So lack of a HoT my not be an outage but simply saving
  energy...

This is excellent work. It shows multihoming in IPv6 is just around the
corner, and not impossible as some people seem to believe.

However, I do see a problem: as this solution isn't well suited to
medium-sized and larger sites, and provides no compatibility with other
solutions that do cater to larger sites, implementing this as-is may not
bring as much benefit as we hope. After all, the majority of all
communication is with at least one non-small site. And I don't think
Google or some other huge site really wants to start doing MIP as a
mattoer of course on all those 200 msec TCP sessions just because the
other side is multihomed.

So what I'd like to see is compatibility with one or more solutions that
are more suited for larger sites. But I guess the first thing we need
for that is one or more solutions that are ore suited for larger sites.  :-)

Iljitsch

---

From: Pekka Savola <[email-masked]>
Date: Sun, 16 Mar 2003 04:06:55 +0200 (EET)

> We would really appreciate your comments,

Some jetlagged comments.

substantial:
------------

==> The problem is that this mechanism only "works" (for some definition of
works) for sessions that are broken over 140 seconds (ie. connection is not
aborted before that), with the upper bound of 420 seconds.  On top of that,
quite a bit of signalling is performed just in case that a link might go
down.

Needless to say, this doesn't seem to be all that useful, the tradeoffs
would seem to be quite overwhelming: especially the 140 seconds; I'd say
the outage of 10-20 seconds is the most that's acceptable for most
connections to stay properly alive.

==> however, I appreciate thinking the whole thing through.. however, as 
it is, the doc is quite heavy to read as it's full of gritty details 
(which are nice when you want to get down to it, and verify it), but more 
focus should be given to the big picture..

==> there is a need for a shorter overview before section 4.3

==> sect 4.3 must be split into smaller pieces

   In the application scenario, according to [3],

   Site Exit Anycast Addresses for ISPA is
   PA:Site:FFFF:FFFF:FFFF:FFFF:FFFF (Hereafter SEAAA)

   Site Exit Anycast Addresses for ISPB is
   PB:Site:FFFF:FFFF:FFFF:FFFF:FFFF (Hereafter SEAAB)

   Then, MHH will try first to send a first packet with:

==> these values seem to be irrelevant, remove.  Btw, how does a node know the
prefix length of his site?  Not an easy problem, unless it's guessing..

editorials:
-----------

     Application of the MIPv6 protocol to the multi-homing problem

==> uppercase the first chars of the most words
==> same goes for the section titles

   This note attempts to describe how to apply the MIPv6 protocol to

==> s/MIPv6/Mobile IPv6 (MIPv6)/

1. Introduction

==> split the section; too long paragraphs are difficult to read
==> actually, a lot of paragraphs should be split up

   1- A path failure detection mechanism, that enables end-hosts to

==> s/,//

4.2.3 Required capability #1

==> reqs should be listed in order or numbered differently

   alternative ISP is to be used for coursing packets. Source address

==> I'm not sure what you mean by "coursing" but I suggest using another :-)
(many other places..)

   the second message. IF this is the case, a BU message is sent,

==> s/IF/If/

   Finally, this solution does not requires that multi-homed sites to

==> s/requires that/require/

References

   [1]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
        IPv6", Internet Draft, Work in progress, May 2002.

==> split the refs
==> s/J. Arkko/Arkko, J./ (same everywhere)

---

From: marcelo bagnulo <[email-masked]>
Date: 16 Mar 2003 20:25:33 +0100

Hi Pekka,

Thank for your comments, they are very welcomed.

> substantial:
Initial comment: the idea of the draft is to assess if MIPv6 can be used
unmodified to support multi-homing. A possible conclusion of this
analysis could be that it is not possible, but i am not sure that this
is clear yet.

> works)

Preserves established sessions perhaps?

>  for sessions that are broken over 140 seconds

This is an upper bound. I mean it can be reduced but it can not be
increased. In order to reduce it all that it is needed is to increase
the frequency of HoTI CoTI message exchange. This would indeed increase
the overhead, and cost benefit analysis should be performed in order to
obtain an optimal choice. What it can not be done is to have a longer
detection period. But if i understand correctly you do not have a
problem with this.

Mechanism that provide a faster response to failures have to be included
once that other problems have been solved (like the next one)

>  (ie. connection is not
> aborted before that), with the upper bound of 420 seconds. 

This is the real problem IMO.The alternative address can only be used 
for a limited period (420 secs). Then you have to
perform the RR procedure again to obtain new valid authorization data
that is to be used for extending the lifetime of the new address. THis
is a major problem since you can not perform the RR procedure because
the HoA is no longer available. The solution for this would be to extend
the lifetime of the binding but this may have security implications. you
have previously worked in MIPv6 security, right? could you comment about
the security concerns of extending this timer? 

>  On top of that,

e2e failure detection implies traffic exchange. It is important to
discuss whether this overhead is acceptable or not. However this is not
strictly related with the usage of MIP but with host based solutions
IMO. I have studied an alternative for this in
http://www.it.uc3m.es/marcelo/mhExtHdr.txt
But it did present some other issues though... 

> connections to stay properly alive.

Great. THis part can be solved, i think. Higher frequency would provide
this with an acceptable cost, i think. Specially when piggybacking is
included in MIPv6. As i said earlier, if this is deemed acceptable, the
message exchange for failure detection needs to be  reasonably tuned.
Moreover, probably adaptive mechanisms are needed to provide a
reasonably good performance. But i think this can be done (once that
other issues are solved, specially the 420 secs timer) 

> ==> there is a need for a shorter overview before section 4.3
Ok, i'll try to do this

> ==> these values seem to be irrelevant, remove. 
 
>  Btw, how does a node know the

Good point!!!
An option is to consider that it is always a /48, but i don't thik this
is a good approach.
Another possibility is to assign the site exit routers anycast address
of every subnet to the corresponding exit router and propagate it within
the site as a host route. So hosts will address packets to its own
subnet exit site router anycast address, which will be routed to the
correspondent exit router.
Since the explanation is not so clear i will put an example

                +----+                  +----+ 
                |R1  |                  |R2  |
                |P1::|                  |P2::|
                +----+                  +----+ 
P1:Subnet1:Router1 |    P2:Subnet2:Router2 |
            -------------------------------------
            P1:Subnet1:Router3 |
            P2:Subnet2:Router3 |            
                            +----+                   
                            |R3  |                  
                            +----+                  
            P1:Subnet3:Router3 |
            P2:Subnet4:Router3 |
           -----------------------------------            
            P1:Subnet3:Host  |
            P2:Subnet4:Host  |            
                          +----+                   
                          |Host|                  
                          +----+                  
 So Addresses P1:Subnet1:FFFF:FFFF:FFFF:FFFF and
P1:Subnet3:FFFF:FFFF:FFFF:FFFF are assigned to R1.
P1:Subnet3:FFFF:FFFF:FFFF:FFFF is announced within the site as a host
route to R1
Addresses P2:Subnet2:FFFF:FFFF:FFFF:FFFF and
P2:Subnet4:FFFF:FFFF:FFFF:FFFF are assigned to R2.
P2:Subnet4:FFFF:FFFF:FFFF:FFFF is announced within the site as a host
route to R2
So when Host sends a packet whose source address contains the prefix P1,
it includes a routing header with P1:Subnet3:FFFF:FFFF:FFFF:FFFF which
is deduced from its own prefix.

Not very nice, but i guess this would work, don't you?  

> editorials:
will fix, thanks.

Thanks again for your feedback, regards, marcelo

-- 
marcelo bagnulo <[email-masked]>
uc3m

---

From: marcelo bagnulo <[email-masked]>
Date: 16 Mar 2003 20:25:27 +0100

Hi Iljitsch,

Thanks you very much for your feedback. Comments below...

>   beforehand when there is still return routability. 

Right. That is what MIPv6 does and the idea is to try to use without
modifications (if possible)

> But can you then
There are two issues here that need to be differentiated:
- First the Return Routability procedure provides BU authorization data
that has a limited lifetime, so it is not permitted by the spec that you
have an alternative address in "standby" as you reasonably suggest.
MIPv6 spec demands the HoTI CoTI exchange to be performed periodically.
This is cumbersome, but i think it can be used as a failure detection
mechanism, which would provide an added value to the RR procedure in its
application to multi-homing.
- The second and really major problem is that you can only use the
alternative address for a limited period (420 secs). Then you have to
perform the RR procedure again to obtain new valid authorization data
that is to be used for extending the lifetime of the new address. THis
is a major problem since you can not perform the RR procedure because
the HoA is no longer available. The solution for this would be to extend
the lifetime of the binding but this may have security implications that
have to be studied

>   another logged in and gotten the same address.)
Agree. I guess that the HoTI CoTI exchange is better suited for this
application then.

>   other side, something must be broken. This probably needs per-session

A proposed extension for MIPv6 is the piggybacking of mobility messages
in regular traffic. In this case you would use return traffic to
transport signaling data. This kind of optimizations can be done.
However this mechanism allows the it is used also in unidirectional
traffic, which i guess is a good feature 

>   most popular networked application typically chokes if the first address
Good point. I do not have much data about how applications normally
behave in this case. But if this is the case, this is an issue. However,
AFAIK this is probably the case for IPv4 where interfaces usually have
only one address configured. However in IPv6, considering "Default
Address Selection mechanism" i was hoping that application used the list
of addresses generated by the mechanism and try to use them to
communicate

>   matter. So lack of a HoT my not be an outage but simply saving

Good point again. Perhaps additional intelligence could be included in
the mechanism to cope with this, i will think it over. 
> corner, and not impossible as some people seem to believe.

Thanks :-)

> medium-sized and larger sites,

indeed

>  and provides no compatibility with other
> solutions that do cater to larger sites,

I am not certain about this. We could study compatibility between
solutions and see what happens. I guess that there is no compatibility
problems between this solution and the classical IPv4 solution... :-)
Really, This is very relevant point to consider seriously and i 'll try
to study it. What solutions do you think i should consider?

>  implementing this as-is may not

Not so sure about that. I mean, Google only has to do the CN RO support,
which will be probably included in most stacks (besides, probably Google
will want to be accessed by mobile hosts) So, it will really won't be
able to tell the difference whether this is a multi-homed host or a
mobile host.

> for that is one or more solutions that are ore suited for larger sites.  :-)
Again i think this a very valid point and i will try to study
compatibility with some of the solutions that we have

Thanks again for your valuable feedback. marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 Mar 2003 11:36:23 +0100 (CET)

> transport signaling data. This kind of optimizations can be done.

I didn't mean including explicit signaling in the normal traffic, but
just _looking_ at the normal traffic to see if everything still works.
This could work by having a list of destination hosts we're
communicating with. Each time a normal-looking packet (ie non-ICMP,
non-tunnel, non-multicast, big enough so it's not just an ACK) goes out,
some session state is saved and a timer is started. When the timer
elapses (after 5 or 10 seconds or so)  without any return traffic, we do
a "real" reachability check. So during normal traffic flow, there is no
need for explicit or piggy-backed reachability checks. This probably
needs some more heuristics, but I think it could work well.

> traffic, which i guess is a good feature

All regular unicast protocols need some form of acknowledgement in order
to keep the traffic flowing. Without this, traffic would continue to
flow long after the receiver has disappeared. That would be extremely
bad.

> only one address configured.

The number of addresses per interface isn't really an issue, I would
think. In v4 having several addresses for a DNS name isn't all that
unusual:

> host www.cnn.com
www.cnn.com is a nickname for cnn.com
cnn.com has address 64.236.24.28
cnn.com has address 64.236.16.20
cnn.com has address 64.236.16.52
cnn.com has address 64.236.16.84
cnn.com has address 64.236.16.116
cnn.com has address 64.236.24.4
cnn.com has address 64.236.24.12
cnn.com has address 64.236.24.20

> However in IPv6, considering "Default

Actually this may make it worse, as the "best" address is always
selected. If the "best" address is unreachable, no dice. At least with
random or round robin you can hit reload to try again.

Iljitsch

---

From: marcelo bagnulo <[email-masked]>
Date: 17 Mar 2003 15:26:21 +0100

> needs some more heuristics, but I think it could work well.

I agree that better and more optimal failure detection can be provided,
which could use some of these ideas.
I am more worried about MIPv6 timers though...
[...]
> random or round robin you can hit reload to try again.
Sorry i am probably missing something...
>From RFC 3484

6. Destination Address Selection

   The destination address selection algorithm takes a list of
   destination addresses and sorts the addresses to produce a new list.
                                                                  ^^^^
I guess that applications now obtain a list of addresses, after the
default address selection mechanism has sorted them.
Moreover, the first rule of the mechanism discards unreachable
destinations, so if one of multiple is unreachable it will be included
last.

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 Mar 2003 18:00:27 +0100 (CET)

> default address selection mechanism has sorted them.

Yes. But then the application still has to go through the trouble of
trying every address. I don't think web browsers typically do that. (And
if the user has to wait for a timeout, it might not matter anyway.)

For your experimentation pleasure I have created some DNS names with 7
IPv4 and/or IPv6 addresses, only one of which works. It's a Cisco, so
you can telnet, but HTTP is probably more interesting (if it works,
you'll get an authentication requester). The names are:

tryme.bgpexpert.com trymev4.bgpexpert.com trymev6.bgpexpert.com

> destinations, so if one of multiple is unreachable it will be included

How does the resolver library know which addresses are reachable? Or
usable for the application in question?

---

From: marcelo bagnulo <[email-masked]>
Date: 17 Mar 2003 20:40:19 +0100

> tryme.bgpexpert.com trymev4.bgpexpert.com trymev6.bgpexpert.com

Thank you very much !!!

We have tried it with the Konqueror browser.
Its behaviour was:

It tried with the first address => it was a "fake" address so it failed
but it received a host unreachable message (almost immediately)
Then it tried with the next one => it was the good one Ok!

This seems to be an suitable behaviour for our needs, right?

(What i didn't told you is that it only tries with 2 addresses, so if
the real one was the third, it would have failed)

So it seems to me that different aps have different behaviour.

I still think that this is reasonable mechanism for selecting the first
address, it is pretty fast if the host unreachable message is sent,
also. 
But i do agree with you that it is application dependent. Perhaps we
need more feedback from application developers?

> usable for the application in question?

It tries and if it is not working, this result is cached for next
attempts (this is one possible mechanism included in the spec)

Regards, marcelo

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Mar 2003 02:58:21 +0200 (EET)

> Preserves established sessions perhaps?

Yes -- with certain tradeoffs: to preserve established sessions, you 
*typically* have to react quickly, and of course the sessions should be 
preservable for the duration of the failure, but that's not as hard a 
requirement to me (ie. if you get a warning that connections have failed, 
using backups whic will help you for the next 5 minutes, shut them down 
gracefully if the break is expected to last longer).

> once that other problems have been solved (like the next one)

Yes, definitely the reaction time would have to be shorter.  However, I'm 
not sure if the HOTI/COTI exchange is the right mechanism for that: I'm 
not sure whether it scales down properly. (It was never meant as a 
heartbeat mechanism.)
 
> the security concerns of extending this timer? 

Due to the RR procedure, it doesn't protect you from on-the-link or 
on-the-path attackers.  Attackers which *have been* on the link or on the 
path can wreak havoc to up to MAX_RR_BINDING_LIFETIME (420 s) after 
leaving the link or the path.

Cranking it up significantly would certainly have implications but slight 
modifications probably not so much (e.g. if your friendly router 
implementation rebooting takes 430 seconds, the lifetime could very well 
be 600 seconds).  The order of magnitude matters.

.. but there may be something I'm missing.

> discuss whether this overhead is acceptable or not. 

Indeed -- some mechanism do this always, some just after the fact (when 
suspecting some error has occurred, e.g. TCP acks get delayed), some both.

> Since the explanation is not so clear i will put an example

Doesn't work -- the host will detect that the prefix is on-link, and will 
try to reach it by sending neighbor solicitation to it.  The access router 
would have to perform proxy-ND for it.

---

From: marcelo bagnulo <[email-masked]>
Date: 19 Mar 2003 22:03:59 +0100

> gracefully if the break is expected to last longer).

I like this approach. However, i would really prefer that connections
could survive longer.

> not sure whether it scales down properly. (It was never meant as a 

I was, however designed to prevent DoS attacks, imposing minimal
workload to CN. No state nor crypto is needed to generate HoT or CoT
messages. I would say it is ok...

> .. but there may be something I'm missing.

Again, i think that the solution would be much more valuable if
connections could survive much longer. I have a proposal to extend
MAX_RR_BINDING_LIFETIME, but it is a bit long to include it in here. If
you would like to consider it, i can send it to you. (i would appreciate
it very much)  

> would have to perform proxy-ND for it.

Good point (again)

I am running out of solutions here :-)
I can think of the following options for this, but i am not sure i like
anyone of them.

First option: (i think this would be the most elegant, but i think its
time has passed) use a site local anycast address
So you can compose the site exit router anycast address by appending the
prefix assigned to the link to the site local prefix. I like this, but
the problem is that there may be no more site locals for connected
sites. I guess i should wait and see the outcome of the site local
debate.

Second option: use the above configuration and configure R3 as a ND
proxy. I do not like this much because it imposes additional
configuration in all the routers (it is better than configuring all the
hosts, though)

Third option: (nasty hack) use the above configuration but change the
site exit router anycast format by changing the less significant bit of
the directly attached subnet. This would make that the anycast address
is not on-link, so that it has to be routed through a router. 

Opinions?
Regards, marcelo

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 21 Mar 2003 00:30:04 +0100

> usable for the application in question?

It doesn't. If time out it will retry.

- kurtis -

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Mar 2003 08:59:12 +0200 (EET)

> is not on-link, so that it has to be routed through a router. 

1) is out of question, 2) seems undesirable but acceptable, 3) too hacky.

A possibly valid approach could be advertising the addresses or portions
of significant information thereof (e.g. prefix length and have a reserved
anycast address) in route advertisements.

But I don't really like this approach either.

A discovery approach would also be possible: e.g. send traceroutes using
all the source addresses and watch out for responses (assuming there is
some special "site exit router discovery" ICMP message).