Subject: noid and applications (generic requirements from applications)

From: Patrik Fältström <[email-masked]>
Date: Wed, 12 Nov 2003 17:10:13 -0600

I have read through draft-nordmark-multi6-noid-01.txt from an 
applications perspective, and I have some generic questions. There are 
of course many parts of the draft which I don't understand, so there 
might be answers hidden somewhere.

I like pictures though ;-)

In draft-nordmark-multi6-noid-01.txt there is a picture:

       ----------------------           ----------------------
       | Sender A           |           | Receiver B         |
       |                    |           |                    |
       |      ULP           |           |      ULP           |
       |       | src AID(A) |           |       ^            |
       |       | dst AID(B) |           |       | src AID(A) |
       |       v            |           |       | dst AID(B) |
       |       M6           |           |       M6           |
       |       | src L1(A)  |           |       ^            |
       |       | dst L1(B)  |           |       | src L2(A)  |
       |       v            |           |       | dst L1(B)  |
       |       IP           |           |       IP           |
       ----------------------           ----------------------
               |                                ^
               -- cloud with some routers -------
                                           src L2(A) [Rewritten]
                                           dst L1(B)
    Figure 2: Mapping with router rewriting of locators.

In this picture A send thinsg to B, and use as src AID(A) and dst 
AID(B).

Questions:

If B send a packet back to A, can AID(B) be used as src, and AID(A) as 
dst?

If B send a packet to C with src AID(B) and dst AID(C), can B send 
AID(A) to C so C can use src AID(C) and dst AID(A)?

If both of these are true, let's dive into DNS/application issues...

       paf

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Nov 2003 03:45:04 +0100 (CET)

> If B send a packet back to A, can AID(B) be used as src, and AID(A) as 

Yes. That is what most ULPs will do.

> AID(A) to C so C can use src AID(C) and dst AID(A)?

Yes, the AIDs can be used for referrals since they are not really different
than today's IP addresses; they are locators.
The only thing to consider is when AID(A) isn't working as a locator when
C tries to contact it.

There are two choices:
C can detect that the locator doesn't work and do a reverse+forward DNS
lookup to get the whole locator set (Ls(A)).
or
The referal can include Ls(A) instead of just the AID(A); this requires
modifying existing IPv6 appication protocols which do referal.

  Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Nov 2003 21:11:05 -0600

> modifying existing IPv6 appication protocols which do referal.

I think it would be a good idea to look at a referral API. Such an API 
would allow a host to ask the system to create a neat little package 
containing all the pertinent locator and identifier information, then 
it can transmit this package to a correspondent and the correspondent 
can then unwrap it and use the content to do whatever it needed the 
referral for. The advantage of such a system is that it could allow 
applications that need referral to be completely independent of lower 
layer technologies, such as the multihoming solution we're going to 
implement, and the differences between IPv4 and IPv6. The downside 
would be that this referral package could get significantly larger than 
a simple address.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 13 Nov 2003 14:36:55 +0100

On torsdag, nov 13, 2003, at 04:11 Europe/Stockholm, Iljitsch van 
Beijnum wrote:

> would be that this referral package could get significantly larger 
> than a simple address.

Although I am tempted to say that a multi6 API with ULP hints, referral 
package, etc is a good idea - I am not sure I think that is where we 
should be right now. This will mean that applications will have to be 
rewritten in order to make full use of the mulihoming solution. Maybe 
this is another topic for Elliot's draft?

- - kurtis -

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Thu, 13 Nov 2003 22:11:19 +0100

On Thursday 13 November 2003 14:36, Kurt Erik Lindqvist wrote:
> - kurtis -

The Ilijtshc's comment raise the question whether multihoming should be
solved at the IP layer. I'm sure that applications can find out a (better) 
multihoming solution.

-- 
******
JFRH
******

Real computer scientists admire ADA for its overwhelming aesthetic
value but they find it difficult to actually program in it, as it is
much too large to implement.  Most computer scientists don't notice
this because they are still arguing over what else to add to ADA.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Nov 2003 23:17:25 +0100

> solved at the IP layer. I'm sure that applications can find out a (better)

There are in fact many applications that succesfully survive connectivity
changes, but this WG is chartered to work on *site* multihoming for IPv6
and that seems to imply layer 3 or layer 4 solutions.

    Brian

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 13 Nov 2003 23:40:46 +0100

On torsdag, nov 13, 2003, at 22:11 Europe/Stockholm, Juan Rodriguez 

> solved at the IP layer. I'm sure that applications can find out a 

I don't agree with that line of thought.  One does not imply the other.

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Nov 2003 20:55:45 +0900

Juan Rodriguez Hervella;
 
> solved at the IP layer. I'm sure that applications can find out a (better) 

Exactly. See my draft at 

   http://www.ietf.org/internet-drafts/draft-ohta-e2e-multihoming-05.txt

However, the problem is that there is some insisting on not
changing anything at upper layers.

To accomodate them, people are trying to invent interim layers,
which does not really change anything, except for rhetoric.

It is easy to introduce a layer to modify packet format
to be identical to the existing one. However, it is still
necessary to introduce new API to notify new kinds of
events to exsiting layers.

						Masataka Ohta