Subject: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgot one [Was: RFC 5889)

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 2 Aug 2010 17:14:05 -0700

Hello all,

At the IETF78 meeting, we had the rough consensus to adapt 
the Erik's modification for RFC5889 in the room. 

To confirm our consensus on the list, we ask the WG consensus call 
for adaption of Erik's modification for RFC5889.

The detailed modifications can be found at the attached email below. Thanks Erik.

Please vote for your opinion before "Aug 9th 12:00PM (PST)". 
If you have any objections, please give us clear reason and propose your text.

thanks in advance,
Thomas, ryuji

Begin forwarded message:

> From: Erik Nordmark <[email-masked]>
> Date: 2010/07/30 01:12:41GMT-07:00
> To: [email-masked]
> Subject: Re: [Autoconf] Forgot one [Was: RFC 5889
> 
> 
> Please double-check this, but I think it has all the list of changes that Jari said verbally.
> 
>  Erik
> 
> ----
> 
> Change the title
> FROM
>                IP Addressing Model in Ad Hoc Networks
> TO
>                A Router Addressing Model in Ad Hoc Networks
> 
> In section 5:
> OLD:
> Routing protocols running on a router may exhibit different
> requirements for uniqueness of interface addresses; some have no such
> requirements, others have requirements ranging from local uniqueness
> only, to uniqueness within, at least, the routing domain (as defined
> in [RFC1136]).
> 
> Configuring an IP address that is unique within the routing domain
> satisfies the less stringent uniqueness requirements of local
> uniqueness, while also enabling protocols which have the most
> stringent requirements of uniqueness within the routing domain.  This
> suggests the following principle:
> 
> o  an IP address assigned to an interface that connects to a link
>   with undetermined connectivity properties should be unique, at
>   least within the routing domain.
> NEW:
> Routing protocols running on a router may exhibit different
> requirements for uniqueness of interface addresses; some have no such
> requirements, others have requirements ranging from local uniqueness
> only, to uniqueness within, at least, the routing domain (as defined
> in [RFC1136]).
> Routing protocols that do not require unique IP addresses within the
> routing domain utilize a separate unique identifier within the routing
> protocol itself; such identifiers could be based on factory assignment
> or configuration.
> 
> Nevertheless, configuring an IP address that is unique within the routing
> domain satisfies the less stringent uniqueness requirements of local
> uniqueness, while also enabling protocols which have the most
> stringent requirements of uniqueness within the routing domain.  As a result, the following principle allows for IP autoconfiguration to
> apply to the widest array of routing protocols:
> 
> o  an IP address assigned to an interface that connects to a link
>   with undetermined connectivity properties should be unique, at
>   least within the routing domain.
> 
> In Section 6.1:
> OLD:
> o  There is no mechanism to ensure that IPv6 link-local addresses are
>   unique across multiple links, hence they cannot be used to
>   reliably identify routers (it is often desirable to identify a
>   router with an IP address).
> NEW:
> o  In general there is no mechanism to ensure that IPv6 link-local
>   addresses are unique across multiple links, however link-local
>   addresses using an IID that are of the modified EUI-64 form are
>   globally unique. Thus if link-local addresses are used to reliably
>   identify routers then they must be of the modified EUI-64 form.
> 
> ---
> _______________________________________________
> Autoconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/autoconf

---

From: Jari Arkko <[email-masked]>
Date: Tue, 03 Aug 2010 11:36:32 +0300

These changes look good to me. Thanks for collecting the right text, Erik.

Jari

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 03 Aug 2010 10:56:29 -0700

Hello folks,

I disagree that the addressing model and the
implications upon link-local addressability
are any less valid for hosts than they are
for routers.

The danger I see is that the title change
could at any time be cited as justification
for restricting the work of [autoconf]
so that only routers can get addresses.
This sort of political device is often able
to overcome any objection that the earlier
language in previous documents was having
unintentional side-effects (once they are
published).

The point was raised during the meeting that
any router could pretend to be a host by simply
setting willingness == 0.

It was not explained why an energy-constrained
device should have to implement thousands of lines
of code just so it could have the privilege of
being called a router when it should never ever
be configured to forward packets.

But perhaps I digress from the point of the
consensus call.

Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 4 Aug 2010 07:27:33 +0200

> setting willingness == 0.
This would still be a node sending out HELLO (and maybe even TC messages if it 
has an attached network), so I would still consider it a router, just with a 
special configuration.

> be configured to forward packets.
I think the problem is that the scope of the address model has no clear 
border. It should be done on the routers (but MANETs can and have been run 
with different address models), and it could be used for hosts closely 
attached to a MANET, but it's not necessary to do so.

But in my opinion it is still better it's still better to restrict the title 
as suggested in the WG meeting consensus that to make it too generic.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: Henning Rogge <[email-masked]>
Date: Wed, 4 Aug 2010 07:29:48 +0200

> If you have any objections, please give us clear reason and propose your
Same as on the WG meeting in Maastricht, I vote for the change.

Henning Rogge

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 03 Aug 2010 22:41:01 -0700

Hello Henning,

> has an attached network), so I would still consider it a router, just with a

This is beside the point.  Hosts need addresses,
and if the only way they can get them is to be
routers, then something is wrong.

> border.

The scope is difficult to define -- that's the
problem.  The ad hoc network could be defined as the
union of the ranges of the nodes in it, and then
the border to be the border of that set (neglecting
certain details).  This still does not materially
explain why a host should implement all that code.

> It should be done on the routers (but MANETs can and have been run

What is "it"?

> as suggested in the WG meeting consensus that to make it too generic.

I can't imagine any non-political reason whatsoever for this.

Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 4 Aug 2010 07:55:58 +0200

On Wed August 4 2010 07:41:01 Charles E. Perkins wrote:
> > This would still be a node sending out HELLO (and maybe even TC messages
> > if it has an attached network), so I would still consider it a router,
> > just with a special configuration.
> 
If you run a part of the routing protocol to connect the "host" to the MANET, 
it's a router in my oppinion (Ripple would call it a leaf node for example).

If the node just use DHCP or similar protocols to get it's address without 
being modified to work with the MANET, it's no router (and don't need the 
autoconf address model).

The autoconf model is NOT the only way for a host to get an address for 
connection to a MANET.

> explain why a host should implement all that code.
I don't remember that anyone demands that such "leaf nodes" have to run the 
complete routing daemon.

If you have a router with a policy that limits the routers functionality (in 
terms of the routing protocol), you could just write a compact/optimized 
version of the needed software part for it.

> > attached to a MANET, but it's not necessary to do so.
The autoconf address model should be used on routers (but you could use a 
different one) and it (the address model) could be used on hosts attached to a 
MANET, but it's not necessary to use the autoconf address model on hosts.
 
> > But in my opinion it is still better it's still better to restrict the
> > title as suggested in the WG meeting consensus that to make it too
> > generic.
> 
If we do otherwise we could have the same problems. People would say "you 
demand that any computer attached to your MANET use the autoconf address 
model. But we have to use DHCP, so your address model is wrong."
(I don't say they are right, but we will get people with strange comments on 
the address model with both titles)

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Wed, 4 Aug 2010 08:48:40 +0200

Charlie,

I see it this way:

What makes a node a router? (mentioned in meeting, maybe incomplete lsit)

a) The device MAY forward packets. Even the case if it actually doesn't, 
e.g. the topology is such that no packet is sent to it for forwarding. Many 
OSses have a "Forwarding" config flag. When on, it is a router. This has 
nothing to do with routing protocols.

b) The device sends out a routing protocol packet. The intention of the
device is arranging topology state, for itself or for neighbors. Hosts may
use a passive mode (often used with RIP). There are some corner cases, like
management boxes that get topology from OSPF/ISIS or BGP by adjacency with
real router. But often, such adjacency leads to topology change and thus the 
management box is a router.

c) The device sends out an RA. Hosts MAY NOT do this.

Why is this important? Especially on b):
Lets say router with reactive protocol sends RREQs but not RREPs.
The router will be part of the topology, but never will receive a packet for
forwarding. But still, it is a router. Willingness=0 is example for an proactive 
protocol.

If a host uses tobe-RFC5889 and only uses a /128 prefix, and other nearby nodes
also use /128's, there is no connectivity. 1-hop neighbors can't know that the
host is reachable. I experienced this problem during maintenance or outage of
the routing protocol, I couldn't remotely repair. That is why I use another 
addressing model, that doesn't has this shortcoming. It supports all types of 
nodes. A big, big difference.

This is why I support the title change.

Regards, Teco

---

From: Teco Boot <[email-masked]>
Date: Wed, 4 Aug 2010 11:01:08 +0200

One problem and proposal for correction. I don't want to delay the process, 
so accepting or rejecting it is acceptable (RFC is informational, so 
I can ignore all what it says). I suggest authors, ADs, chairs and Erik 
decide.

The NEW text says: "must be of the modified EUI-64 form".
There can be other mechanisms that assure uniqueness. Other text says: 
"such identifiers could be based on factory assignment or configuration".
The new text will bring a consistency problem in the document.
A _should_ helps:

NEWER:
 identify routers then they should be of the modified EUI-64 form.
                            ------

Christopher Dearlove brought up same issue: 
http://www.ietf.org/mail-archive/web/autoconf/current/msg02736.html
He suggests removing the last text sentence completely:
<Chris>

NEW:
     globally unique.

(Personally, I'd modify that a little further, to:

  o  In general there is no mechanism to ensure that IPv6 link-local
     addresses are unique across multiple links, however link-local
     addresses using an IID that are of the modified EUI-64 form
     ahould be globally unique

</Chris>

With correction "ahould" to "should", I support this last proposal.
Less text is better.

Teco

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Aug 2010 12:00:33 +0200

I'd capitalize "Modified EUI-64", as RFC4291 puts it.

> "such identifiers could be based on factory assignment or configuration".

Hmmm... would this factory assignment be in agreement with the 'u' and 
'g' bits of the Modified EUI-64 format?  If yes, then there wouldn't be 
a need to mention such identifiers.

If no - then we don't talk Modified EUI-64, and we can't say that the 
global uniqueness could be guaranteed by factory assignment, I think.

Alex

>>> From: Erik Nordmark<[email-masked]>

---

From: Teco Boot <[email-masked]>
Date: Wed, 4 Aug 2010 12:35:55 +0200

You mix things up.
If you read the text, you'll see the first text is for router identifiers.
The message is that what can be done for router identifiers can be done for
link locals also. Let's be consistent.

Teco

Op 4 aug 2010, om 12:00 heeft Alexandru Petrescu het volgende geschreven:

> Hmmm... would this factory assignment be in agreement with the 'u' and 'g' bits of the Modified EUI-64 format?  If yes, then there wouldn't be a need to mention such identifiers.
> 
> If no - then we don't talk Modified EUI-64, and we can't say that the global uniqueness could be guaranteed by factory assignment, I think.
> 
> Alex
> 
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 04 Aug 2010 06:07:14 -0700

Hello Henning,

> it's a router in my oppinion (Ripple would call it a leaf node for example).

What if your host gets an address by running
"autoconf.exe", which is not a routing program?

> being modified to work with the MANET, it's no router (and don't need the

What if the host does not?  Or, do you mean to say
that this discussion is a way to legislate that all
hosts must use DHCP?

> The autoconf model is NOT the only way for a host to get an address for

The autoconf model for getting addresses doesn't exist.
I sure hope it isn't the only way to get an address.

But suppose at some point there is an autoconf.exe.
It should be a way for a host to get an address.
Its connection to the MANET would, presumably allow
it to use this address.  Or, do you mean to say that
"address allocation" == "connection"?

> version of the needed software part for it.

main()
{
	system ("get_address");
	if (routing) fail();   /* My compact routing code */
}

Am I a router?

> MANET, but it's not necessary to use the autoconf address model on hosts.

It's necessary for hosts to adhere to the
considerations detailed in the address model
document.  I'm not sure if this is the same
as "using" it.

> model. But we have to use DHCP, so your address model is wrong."

This is a political argument not based on the needs
of the addressability, connectivity, or goals of
making an ad hoc network.  Insofar as you may be
nonetheless correct, I begin to believe that I have
zero insight into the technical goals of the discussion.

> the address model with both titles)

Please tell me if my comments are "strange".

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 04 Aug 2010 06:18:12 -0700

Hello Teco,

> nothing to do with routing protocols.

Check.

> b) The device sends out a routing protocol packet.  ...

Check.

> c) The device sends out an RA. Hosts MAY NOT do this.

Check.

...

> also use /128's, there is no connectivity.

What about point-to-point links?

> 1-hop neighbors can't know that the
> host is reachable.

What about point-to-point links?

> I experienced this problem during maintenance or outage of

I never experienced this with AODV, which
could use all point-to-point links.

> This is why I support the title change.

I'm still mystified, unless (as Henning opines)
we've strayed into the magical land of politics.

Regards,
Charlie P.

---

From: Teco Boot <[email-masked]>
Date: Wed, 4 Aug 2010 17:37:02 +0200

> What about point-to-point links?

Even then, a host would not use this link if it is not mentioned in the routing table.
You could say a host with one p2p link could set the default gateway automatically.
But how can the opposite node learn the topology?
If it is a single-homed host, this small setup of only two hosts would work.
Any other case results in nothing.

> could use all point-to-point links.

So you stop AODV, and AODV still operates???
Can't be.

> we've strayed into the magical land of politics.

A node that runs AODV is a router, because AODV is a routing protocol.
More detailed answer: in AODV, the subnet router is responsible for 
reachability for the subnet. In our addressing model, with /128 subnet, 
there is only one node in the subnet, that is the subnet router.
So the document applies only to routers in ad hoc networks.

Demystified ?

We can discuss wrongly used _host_ in HIP, DHCP, Host Route etc., if time permits.
Not for today.

Teco

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 04 Aug 2010 09:17:22 -0700

Hello Teco,

Comments below:

> Even then, a host would not use this link if it is not mentioned in the routing table.

Every host has a routing table.  Do you say
otherwise?  If so, we have no vocabulary.
IPv6 hosts can even have multiple routers
in their routing table.

> But how can the opposite node learn the topology?

Are we getting into solution space?

I didn't even say that a host had to have
a default router.

> Any other case results in nothing.

Without presenting solutions, I cannot
convince you otherwise.  For this discussion,
suffice it to say that I am 100% certain your
statement is incorrect.

> So you stop AODV, and AODV still operates???

I'm sorry, but I cannot understand what
you meant.  Anyway, I wouldn't have
"stopped AODV" unless I broadcast a
directive to all nodes that they must
cease operation.

> A node that runs AODV is a router, because AODV is a routing protocol.

I mentioned AODV as a counterexample to your
statement about the infeasibility of running
a network over /128 links.  It does not mean
that I say "AODV" to every question you might
ask.

In particular, I claim that hosts in an ad hoc
network often must adhere to the developed
address model.  Of course they don't run AODV
if they're not routers.

> reachability for the subnet.

Where's the subnet?

> In our addressing model, with /128 subnet,

Is there some weird magic that requires every
/128 subnet to have an AODV subnet router?
If not, then your conclusion is false.

> Demystified ?

Actually, I am further mystified -- especially
to think that point-to-point routes get so little
respect in this forum, and that anyone might
claim that hosts don't have routing tables.

Do you claim that any program that utilizes
#include <route.h> is a router?

> We can discuss wrongly used _host_ in HIP, DHCP, Host Route etc., if time permits.

Sounds like fun.

Regards,
Charlie P.

---

From: Teco Boot <[email-masked]>
Date: Wed, 4 Aug 2010 20:11:37 +0200

Hi Charlie,

Check.

> Are we getting into solution space?

No. We are getting out-of-scope.
The document is about link with undetermined characteristics.
P2P links are not in that category.

> I didn't even say that a host had to have

Then, that host does not send packets.
(Assuming empty routing table and /128 (v6) or /32 (v4) address prefix). 
(Host learning more specific routes via p2p links could be exception)

> suffice it to say that I am 100% certain your

I think I would call your solution topology exchange, thus routing.
Just guessing, of course.

> directive to all nodes that they must

It is not "all or nothing".
A router could stop acting as router. Think of maintenance, bugs etc.
Sure, before quitting, the router may advertise it's routing protocol 
is gonna die. I don't see why routing protocols on other nodes would 
cease operation. A bit too DOS friendly, I say.

Check.

> address model.  Of course they don't run AODV

OK, now were are there. How can the routers know the host is there?
When the host belongs to a subnet, with a "subnet router" as gateway
to the rest of the network, I am OK. But this cannot happen, with the
current addressing model. 

>> reachability for the subnet.

Somewhere in the network. Optionally with hosts. And a router, connecting
the subnet to the rest of the network.

> If not, then your conclusion is false.

There is no magic.
Point is: with /128, there are no hosts. Not on links with undetermined
characteristics.

> claim that hosts don't have routing tables.

1) P2P is out-of-scope, as we assume nothing for our links.
2) hosts have routing tables.

> #include <route.h> is a router?

No, not at all.
But if this piece of code sends out a routing packet, then yes, for sure.

With IPv6, we could support hosts in our links with undetermined 
characteristics. Router sends RA with PIO (/64), with L-bit is 0.
Nearby hosts can configure own address (SLAAC) and use the router
as gateway. This only works for satellite hosts. This model is 
suggested multiple times (Templin, in't Velt, others).
There was rough consensus not to support this addressing model.

Teco

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 04 Aug 2010 12:38:03 -0700

Hello Teco,

> P2P links are not in that category.

I definitely don't agree with this conclusion.
The links with undetermined characteristics can
support time-bounded P2P links.  There is no
reason to declare P2P links out of scope.

> (Assuming empty routing table and /128 (v6) or /32 (v4) address prefix).

Bad assumption!

> (Host learning more specific routes via p2p links could be exception)

This isn't necessary.  Shall I make an example?

One trivial example would be to just run in
promiscuous mode, listen for addresses, and
pretend that some neighbor is a router.

I have other examples that are more normal :-)

> Just guessing, of course.

I am not claiming that the other solutions are
mine -- but there are numerous examples in the
literature.

As far as a host is concerned, topology
exchange isn't necessary -- unless you call
the simple fact of link establishment to be
"topology exchange".  And then our discussion
fails, because we have so little vocabulary.

> OK, now were are there. How can the routers know the host is there?

If the host transmits a packet, the routers can know.

> current addressing model.

Why not?

If I remember correctly, the current addressing model does
not legislate that all links have to be /128.  It just
says that SOME links appear to be /128, so that without
additional information, protocols may not make too many
assumptions about the connectivity properties of the link.

As many have pointed out, this world is not so black and
white.

> the subnet to the rest of the network.

Optionally.  And, a node can forward packets
based only on P2P routes.  Such a node is,
I claim, a router.  No subnets are needed.

> Point is: with /128, there are no hosts. Not on links with undetermined

Teco -- this is just wrong.

Just because a network interface has undetermined
properties doesn't mean that the host utilizing
that network interface can't transmit or receive
packets.  Otherwise, what would be the point of
powering the interface?

> 1) P2P is out-of-scope, as we assume nothing for our links.

We do assume that hosts can transmit packets.
At least I do.  Hosts that can transmit packets
can support P2P links.  Why not??

> 2) hosts have routing tables.

Well, I'm glad you cleared that up.

> There was rough consensus not to support this addressing model.

What if the router sends out RA with /128, and hosts
receiving the RA configure P2P route table entries to
the router?  That would work.

But it's not the only way, of course.

Regards,
Charlie P.

---

From: Teco Boot <[email-masked]>
Date: Thu, 5 Aug 2010 10:27:26 +0200

Hi Charlie,

> reason to declare P2P links out of scope.

At least P2P is a special case.
Has this to do with our discussion?
Can you come up with something other than p2p?

>> (Assuming empty routing table and /128 (v6) or /32 (v4) address prefix).

Then, what is in the routing table?
And what mechanism takes care?
If it is a routing protocol, the node is router.
It it learns an on-link prefix, it is not using the 
proposed addressing model.
If it learns an off-link prefix, and use the provider of 
this prefix (router sending RA) as default gateway, I am OK.
If it learns other routing info, I am also OK.

I still wonder how two hosts with off-link prefixes on same link can 
communicate.

> This isn't necessary.  Shall I make an example?

This may help.

> pretend that some neighbor is a router.

Data plane populating routing table ??
What about uni-directional link test ??

> I have other examples that are more normal :-)

Please do so, previous one frightened me. 

> mine -- but there are numerous examples in the

Refs are OK. Or describe one.

> fails, because we have so little vocabulary.

We may end up in discussing the width of the grey zone between 
host and router, and the exact borderlines.
We agreed on three indications for classifying node a router.
Now on indications for hosts:
Oldie, RFC1122:
 (c)  Routing complexity should be in the gateways.
         Routing is a complex and difficult problem, and ought to
         be performed by the gateways, not the hosts.  An important
         objective is to insulate host software from changes caused
         by the inevitable evolution of the Internet routing
         architecture
And:
      The host IP layer has two basic functions:  (1) choose the "next
      hop" gateway or host for outgoing IP datagrams and (2) reassemble
      incoming IP datagrams. 
And the whole 3.3.1 section.
RFC5942 is also relevant.

Now I say: there are protocols for host-router relations, so host will 
know on-line prefix and default gateway, or more specific routes.
But what about getting knowledge on routers for links to hosts, where 
hosts have off-link prefixes? If there are protocols for such (and done in 
a clean fashion), I call it routing. This, because hosts do not advertise 
themselves to routers as part of the topology. This is where routing 
complexity starts.

Complexity is increased with RFC5942, with our RFC5889 in mind.
We don't configure on-link prefixes on our interfaces.
RFC5942 Host Behavior (3.1):
   In IPv6, an address is on-link (with respect to a specific link), if
   the address has been assigned to an interface attached to that link.
So one could say we do not comply to RFC5942. Luckily, RFC5942 is for 
hosts.

> If the host transmits a packet, the routers can know.

IMHO mix data plane and routing control plane is bad.

> assumptions about the connectivity properties of the link.

It says no on-link subnet prefix is configured.
As a result, hosts are not supported. Some mechanism
is needed making the router aware that other nodes
are reachable via this interface. I call this routing.

> As many have pointed out, this world is not so black and

Indeed. But it is quite dark for hosts, using this addressing model.
Routing enlighten.

> I claim, a router.  No subnets are needed.

Back to subject: addressing model is for routers.
You disagreed with title change.
I expect some argumentation. I did't see such.

> packets.  Otherwise, what would be the point of

You miss the point.
When some say routers, they don't intent the node MUST
forward packets. The intention is that routing protocols
are involved getting the routing tables populated. And
bypass limitations for hosts. This is allowed, because 
routers understand the complexity.

> can support P2P links.  Why not??

We need populated routing tables getting packets around.
Without on-link prefixes, hosts have difficulties.

> the router?  That would work.

Maybe.
Any valid received RA info is reflected in default router list.
But how can a host without on-link addresses populate the router 
routing table?

Regards, Teco

---

From: Henning Rogge <[email-masked]>
Date: Thu, 5 Aug 2010 10:38:57 +0200

On Wed August 4 2010 15:07:14 Charles E. Perkins wrote:
> > If you run a part of the routing protocol to connect the "host" to the
> > MANET, it's a router in my oppinion (Ripple would call it a leaf node
> > for example).
> 
Does your host set up a route towards the next router and maintains it if the 
topology data from the router changes ? If yes I would say it's a primitive 
router too. If no, it's not.

> > If the node just use DHCP or similar protocols to get it's address
> > without being modified to work with the MANET, it's no router (and don't
> > need the autoconf address model).
> 
I don't think I ever said this. I just presented an example that the address 
model is not necessary for running a node in a MANET that use the autoconf 
address model.

Yes, you CAN use it... but you don't need to.

> "address allocation" == "connection"?
I don't see any reason why an autoconfiguration protocol developed by this 
group would only run on interfaces of routers.

> > If you have a router with a policy that limits the routers functionality
> > (in terms of the routing protocol), you could just write a
> > compact/optimized version of the needed software part for it.
> 
> main()
> {
> 	system ("get_address");
I don't see any routing code of a routing protocol. But I don't see your 
problem too.

> > different one) and it (the address model) could be used on hosts attached
> > to a MANET, but it's not necessary to use the autoconf address model on
> > hosts.
> 
It might be necessary, depending on what software the host is running.

> > (I don't say they are right, but we will get people with strange comments
> > on the address model with both titles)
> 
I think the problem you stated is that people can say "the title says it's 
only for routers, so it is not enough for my usecase and I need something 
different".

If we not change the title we might get "the title says it's for all nodes, 
but I cannot force my users to install a special interface configuration on 
their smartphones, so I need something different."

There are nodes in MANET that are a grey area between host and router. Because 
of this we cannot make a clear statement on what nodes the autoconf address 
model should be used.

Most of the WG seems to think it's better to restrict the scope a little bit 
more and let people use it for other things than the defined scope if they 
think it's right (at least that's how I understand the consensus of the 
group).

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 5 Aug 2010 09:51:13 +0100

This looks slightly different from the last set I saw. But I
haven't checked.

I really don't want us to hold things up any more. But mandating
EUI-64 under the circumstances noted is I think wrong, and
doubly wrong as what is supposed to be an AUTH-48 error
correction, not a revisit the WG and change things process
(and are the IESG now going to demand to re-confirm the document
also?) Ignoring the procedural issues, I could live with
changing that "must" to "may" (I think even "should" is too
strong). Or dropping that (last sugggested new) sentence.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ryuji Wakikawa
Sent: 03 August 2010 01:14
To: [email-masked] [email-masked]
Cc: Autoconf Chairs; Ralph Droms
Subject: [Autoconf] WC consensus call for RFC5889 modifications (Fwd:
Forgotone [Was: RFC 5889)

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

Hello all,

The detailed modifications can be found at the attached email below.
Thanks Erik.

Please vote for your opinion before "Aug 9th 12:00PM (PST)". 
If you have any objections, please give us clear reason and propose your
text.

thanks in advance,
Thomas, ryuji

Begin forwarded message:

> stringent requirements of uniqueness within the routing domain.  As a
result, the following principle allows for IP autoconfiguration to

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Aug 2010 11:21:37 +0200

> router too. If no, it's not.

To me a router is a device and its software doing this:
- has a routing table called such.
- does longest-prefix match algorithm to search in it.  This operation
   is not specified (no RFC) but it is there everywhere in every router,
   thanks BSD.
- includes that route.h I believe as CP said.
- has multiple interfaces.

In a sense every other host (my Windows PC) is a router because it does 
all these things.  My PDA, my cell phone, are all routers.

 From this perspective, it is difficult to define what a Host is because 
everything seems to be a router to me - once it's connected to the 
Internet it is a router.  A supercomputer is a router too, though it 
won't route as a DFZ 192-processor router would route.

Alex

---

From: Henning Rogge <[email-masked]>
Date: Thu, 5 Aug 2010 11:33:32 +0200

> To me a router is a device and its software doing this:
one of them or all of them ?

Henning Rogge

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Aug 2010 11:39:41 +0200

> one of them or all of them ?

Right, both of them, IMHO.

Alex

---

From: Henning Rogge <[email-masked]>
Date: Thu, 5 Aug 2010 11:42:47 +0200

On Thu August 5 2010 11:39:41 Alexandru Petrescu wrote:
> >>     is not specified (no RFC) but it is there everywhere in every
> >>     router, thanks BSD.
> >> 
That make no sense for a MANET, most MANET routers have only a single 
interface.

And you don't need any header files like route.h on a router, just on your 
development system. I don't think you will find many embedded routers (DSL, 
MANET, ...) with header files on them.

Henning Rogge

---

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 5 Aug 2010 11:47:53 +0200

I share the opinion that this discussion polluted by the unanswered question
"what is the definition of a router?". There are too many different answers
to this question (Thomas mentioned some of them in Maastricht, and other
definitions exist, I'm sure).

Maybe it would be easier to focus on the counterpart instead, and consider
the question "what is the definition of a host?". It seems to me that the
devices we are aiming to configure are typically capable of things that
hosts can't do (including, for instance, forwarding traffic on behalf of
other devices, if necessary).

So the immediate conclusion that most folks make, is: "if it is not a host,
then it is a router". Difficult to blame anyone for making such a deduction,
as the IETF defined a world where you only have these two choices. So I
think, in that sense, we are indeed configuring routers.

Now, if I understand Charlie's point correctly, he raises the question:
"what of the special case where the device we are configuring is really a
host?". This question was already raised some time ago in this working group
(at least while we were discussing the late MANET architecture draft). If I
remember correctly, the rough consensus at that point in time was: "hosts
are considered to be connected to a MANET only through a router, and thus,
the MANET can be considered as comprising of only routers".

This architectural consideration thus separated the issue of "configuring
routers" from the issue of "configuring hosts" in this context, and the
rough consensus was that we would first focus on configuring routers. Which
lead us to where we are now.

However, in the end, Charlie is right: we do want to configure the hosts too
;) So do we want to stick to the original plan (i.e. focus first on router
configuration) or do we want to address instead both router and host
configuration, all at once? I guess this is what it boils down to at this
point.

As far as I am concerned, I think it makes sense to consider the issue of
"configuring routers" from the issue of "configuring hosts" separately
because hosts are and routers have very different capabilities. I'm also
fine with sticking with the original plan, i.e. focus first on router
configuration. But on the way towards solutions for router configuration, I
think we should be careful not to forget the big picture: in the end we want
to also configure hosts. In particular, this means that if an efficient
router configuration solution can easily be extended to become an efficient
host configuration solution, all the better ;)

Emmanuel

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Aug 2010 11:59:54 +0200

Le 05/08/2010 11:42, Henning Rogge a écrit :
>>>> To me a router is a device and its software doing this: - has
>>>> a routing table called such. - does longest-prefix match
>>>> algorithm to search in it.  This operation
>>>>
>>>> - includes that route.h I believe as CP said. - has multiple
>>>> interfaces.

Well, are MANET routers 'routers' at all?

Does a MANET router execute the longest-prefix match algorithm?

Does a MANET router select an output interface depending on the result
of that agorithm?  Or is it just doing it with always the same result?

> And you don't need any header files like route.h on a router, just
> on your development system. I don't think you will find many
> embedded routers (DSL, MANET, ...) with header files on them.

WEll... the /usr/include stuff is there everywhere in the deployed
routers running binaries.  E.g. linux phones.  I think a device that
boots a kernel has a file system and that should have a /usr/include.

Alex

---

From: Teco Boot <[email-masked]>
Date: Thu, 5 Aug 2010 12:21:05 +0200

> Well, are MANET routers 'routers' at all?

Yes.

> Does a MANET router execute the longest-prefix match algorithm?

Yes. Every router MUST. This is Router Requirement (RFC 1812, page 75)
And many other RFCs. Dig yourself.
Also applies to hosts.

> of that agorithm?  Or is it just doing it with always the same result?

Also RFC 1812.

> boots a kernel has a file system and that should have a /usr/include.

Pure non-info.

Teco.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 5 Aug 2010 12:25:48 +0200

Yes.
 
> Does a MANET router execute the longest-prefix match algorithm?
Most MANET routers I'm working with are linux systems... mostly on embedded 
hardware. So the answer is "yes" for the systems I know.
 
> of that agorithm?  Or is it just doing it with always the same result?
Yes... difficult choice between the localhost interface and the only physical 
outgoing interface wlan0.

> boots a kernel has a file system and that should have a /usr/include.
Maybe you should check your facts before you post stuff like this.

I just opened the console of my android smartphone (linux based !) and I was 
not surprised that there are no include files on the device.

Include files are necessary to COMPILE code... not to run it. They are a waste 
of space on embedded linux systems, because you don't have a compiler on them. 
Noone creating a sane distribution for an embedded linux system would add an 
include file to it.

I would bet that neither a windows smartphone, nor a webos palm one, nor an 
iphone has any include header files on it's flash. Unless the user installed 
it afterwards.

Henning Rogge

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 5 Aug 2010 12:29:20 +0200

Alex,

>[...]
> In a sense every other host (my Windows PC) is a router because it does all these things.  My PDA, my cell phone, are all routers.

Well, that seems like a strange definition of a router. In a recent
mail of Teco, he summarized the three typical definitions of routers.
And as Henning said, MANET routers may have a single interface and
still perform routing (in the sense of receiving an incoming IP packet
not destined to the receiving router itself, looking up the next hop
from the routing table using longest-prefix match, and retransmission
on the appropriate network interface).

Ulrich

---

From: Teco Boot <[email-masked]>
Date: Thu, 5 Aug 2010 13:06:19 +0200

Alex,

I guess this mail leads to nothing.
But I give it a try.

>> - has a routing table called such.
All nodes have such. Including hosts.

>>  is not specified (no RFC) but it is there everywhere in every router,
All nodes have such. Including hosts.
Yes, described in RFCs. Started in RFC 1122 (or before), extended in many RFC's. 
Thanks IETF members.

>> - includes that route.h I believe as CP said.
Nonsense.

>> - has multiple interfaces.
All nodes may have such. Including hosts.

>> In a sense every other host (my Windows PC) is a router because it does all these things.  My PDA, my cell phone, are all routers.
Nonsense.

Regards, Teco

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Aug 2010 13:17:56 +0200

Le 05/08/2010 12:25, Henning Rogge a écrit :
>>> That make no sense for a MANET, most MANET routers have only a
>>> single interface.
>>
> Most MANET routers I'm working with are linux systems... mostly on
> embedded hardware. So the answer is "yes" for the systems I know.
>
>
>> Does a MANET router select an output interface depending on the
>> result of that agorithm?  Or is it just doing it with always the
>> same result?
>
> Yes... difficult choice between the localhost interface and the only
>  physical outgoing interface wlan0.

So a MANET Router actually has at least two interfaces, which makes it 
more of a router indeed, in my reading.

>>> And you don't need any header files like route.h on a router,
>>> just on your development system. I don't think you will find
>>> many embedded routers (DSL, MANET, ...) with header files on
>>> them.
>>
>> routers running binaries.  E.g. linux phones.  I think a device
>> that boots a kernel has a file system and that should have a
>> /usr/include.
>
> I just opened the console of my android smartphone (linux based !)
> and I was not surprised that there are no include files on the
> device.

Good to know, I haven't tried android linux.

> Include files are necessary to COMPILE code... not to run it. They

Compile with static or dynamic link edition?

> are a waste of space on embedded linux systems, because you don't
> have a compiler on them. Noone creating a sane distribution for an
> embedded linux system would add an include file to it.
>
> I would bet that neither a windows smartphone, nor a webos palm one,
>  nor an iphone has any include header files on it's flash. Unless the
>  user installed it afterwards.

Libraries .so, .dll, modules .ko and kernel images may need .h at run 
time...

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Aug 2010 13:25:42 +0200

Le 05/08/2010 12:29, Ulrich Herberg a écrit :
> Alex,
>
>> [...] To me a router is a device and its software doing this: - has
>> a routing table called such. - does longest-prefix match algorithm
>> to search in it.  This operation is not specified (no RFC) but it
>> is there everywhere in every router, thanks BSD. - includes that
>> route.h I believe as CP said. - has multiple interfaces.
>>
>> In a sense every other host (my Windows PC) is a router because it
>>  does all these things.  My PDA, my cell phone, are all routers.
>
> mail of Teco, he summarized the three typical definitions of
> routers. And as Henning said, MANET routers may have a single
> interface and still perform routing (in the sense of receiving an
> incoming IP packet not destined to the receiving router itself,
> looking up the next hop from the routing table using longest-prefix
> match, and retransmission on the appropriate network interface).

If the 'appropriate' network interface is always the same interface
becuase there's only one, then... why the need to look it up in a
routing table?  Why the need to select among other routes?

Or is it simply because the longest-prefix match algorithm is there
everywhere, works with any socket () program setting the dst IP address
field, and with a default route set there.

Just because the longest-prefix match algo is called everytime a packet
is sent does not mean to me it _should_ be called.

An optimizer human looking at a router with a single interface and a
single-entry routing table would surely get rid of this latter
including its algo.  Because this happens at each packet and takes
unnecessary time.  And removing this table and algo makes it a no-router.

Alex

---

From: "Rogge Henning" <[email-masked]>
Date: Thu, 5 Aug 2010 13:39:48 +0200

> -----Ursprüngliche Nachricht-----
> Von: Alexandru Petrescu [mailto:[email-masked]] 
> 
> > Yes... difficult choice between the localhost interface and 
> > the only physical outgoing interface wlan0.
> 
> So a MANET Router actually has at least two interfaces, which 
> makes it more of a router indeed, in my reading.
WTF ?

So a computer with two localhost interfaces is a router in your oppinion ?
Funny idea to forwarding a packet with a nexthop on a localhost interface.

> > I just opened the console of my android smartphone (linux 
> based !) and 
> > I was not surprised that there are no include files on the device.
> 
Both of them. Header files DO NOT MATTER except for the compiler.
 
> > are a waste of space on embedded linux systems, because you 
> don't have 
> > a compiler on them. Noone creating a sane distribution for 
> an embedded 
> > linux system would add an include file to it.
> >
> Libraries .so, .dll, modules .ko and kernel images may need 
> .h at run time...
Good luck finding a header file on your windows machine.

Alexandru, please take a break and read some good books about C, operation
systems and compilers. I think you have proven that you need to do some
research.

Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für 
Kommunikation, Informationsverarbeitung und Ergonomie FKIE 
Kommunikationssysteme (KOM) Neuenahrer Straße 20, 53343 Wachtberg, 
Germany Telefon +49 228 9435-961,   Fax +49 228 9435 685 
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Aug 2010 13:44:29 +0200

Le 05/08/2010 12:21, Teco Boot a écrit :
> Yes. Every router MUST. This is Router Requirement (RFC 1812, page
> 75) And many other RFCs. Dig yourself.
 >
> Also applies to hosts.

Hmmm the rfc1812 title says "Reqs for IPv4 Routers" (not hosts)...

Are MANET Routers referring to RFC1812?  BEcause RFC1812 says:
> (1) If a host has only a single constituent-network interface, it
> should not act as a router.

To me that reads that if a device has a single interface then it can't
act as a router.

Also rfc1812 says:
> An Internet router performs the following functions:
[...]
> (2) Interfaces to two or more packet networks.

Since MANET is so vaguely defined, because of the undetermined link
connectivity properties, one wouldn't say that a MANET Router is an
Internet Router.

>> that boots a kernel has a file system and that should have a

WEll.  There are file systems and dynamically compressed file systems.
There are off-the-shelf kernels and home-brewed re-compiled kernels.

Few things are pure :-)

Alex

>
>
> Teco.
>
>
>> Alex
>>
>>>
>>> Henning Rogge
>>
>>
>> _______________________________________________ Autoconf mailing
>> list [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Aug 2010 14:00:02 +0200

> Funny idea to forwarding a packet with a nexthop on a localhost interface.

Funny indeed... it would still route between localhost interfaces, there 
would be choice for tht algo.

> systems and compilers. I think you have proven that you need to do some

Ok, good advice in general.  I will have to look closer at this.  I do 
like the idea of router.h representing a router software though.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Aug 2010 14:06:03 +0200

Le 05/08/2010 13:06, Teco Boot a écrit :
> Alex,
>
> I guess this mail leads to nothing. But I give it a try.
>
>>> To me a router is a device and its software doing this: - has a
>>> routing table called such.
>>> - does longest-prefix match algorithm to search in it.  This
>>> operation is not specified (no RFC) but it is there everywhere
>>> in every router, thanks BSD.
>
> All nodes have such. Including hosts. Yes, described in RFCs.
> Started in RFC 1122 (or before), extended in many RFC's. Thanks IETF
> members.

If you mean rfc1812.  That "longest match" algo:
- is not the longest-prefix match algo
- talks IPv4 only,
- doesn't say how it "examines": it doesn't say bitwise compare
- doesn't treat the fairly common case of multiple entries of same
   prefix same length,
- does not treat the special default route
- has no licensing scheme
- and more.

As written there it's hardly implementable in an interoperable manner
(as compared to a much better of e.g. segment processing of IPv6 rfc2460
pp 16, or the C in rfc3174 SHA1).

That spec works well by example: it gives good examples, although not
any counter example.

Alex

>>> In a sense every other host (my Windows PC) is a router because
>>> it does all these things.  My PDA, my cell phone, are all
>>> routers.
> Nonsense.
>
>
> Regards, Teco

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Aug 2010 14:23:07 +0200

Le 05/08/2010 11:47, Emmanuel Baccelli a écrit :
> I share the opinion that this discussion polluted by the unanswered
> question "what is the definition of a router?". There are too many
> different answers to this question (Thomas mentioned some of them in
>  Maastricht, and other definitions exist, I'm sure).
>
> Maybe it would be easier to focus on the counterpart instead, and
> consider the question "what is the definition of a host?".

That is a good question, looking at it the other way around.

> It seems to me that the devices we are aiming to configure are
> typically capable of things that hosts can't do (including, for
> instance, forwarding traffic on behalf of other devices, if
> necessary).
>
> So the immediate conclusion that most folks make, is: "if it is not a
> host, then it is a router". Difficult to blame anyone for making such
> a deduction,

I agree.  I think this logic "if it is not a host then it is a router"
is not a right logic.  It could be, for example, a multi-homed device,
not routing, yet multiple interfaces, etc.

If it is not a host then it could be a multi-homed host, a router, and
probably more.

> as the IETF defined a world where you only have these two choices.
> So I think, in that sense, we are indeed configuring routers.
>
> Now, if I understand Charlie's point correctly, he raises the
> question: "what of the special case where the device we are
> configuring is really a host?". This question was already raised some
> time ago in this working group (at least while we were discussing the
> late MANET architecture draft). If I remember correctly, the rough
> consensus at that point in time was: "hosts are considered to be
> connected to a MANET only through a router, and thus, the MANET can
> be considered as comprising of only routers".
>
> This architectural consideration thus separated the issue of
> "configuring routers" from the issue of "configuring hosts" in this
> context, and the rough consensus was that we would first focus on
> configuring routers. Which lead us to where we are now.
>
> However, in the end, Charlie is right: we do want to configure the
> hosts too ;)

:-) sounds good.

How about us wanting to configure an "AUTOCONF node"? (a little bit of a
Router, of a Host, and of a MANET Router).

> So do we want to stick to the original plan (i.e. focus first on
> router configuration) or do we want to address instead both router
> and host configuration, all at once? I guess this is what it boils
> down to at this point.

I will be happier if it boiled down to defining an "AUTOCONF node" or
entity, or so.

>
> As far as I am concerned, I think it makes sense to consider the
> issue of "configuring routers" from the issue of "configuring hosts"
>  separately because hosts are and routers have very different
> capabilities. I'm also fine with sticking with the original plan,
> i.e. focus first on router configuration. But on the way towards
> solutions for router configuration, I think we should be careful not
>  to forget the big picture: in the end we want to also configure
> hosts. In particular, this means that if an efficient router
> configuration solution can easily be extended to become an efficient

Reads good.

Alex

>
>
> Emmanuel
>
>
>
>
>
>
>
> On Thu, Aug 5, 2010 at 10:38 AM, Henning Rogge
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> What if your host gets an address by running "autoconf.exe", which
>>  is not a routing program?
> Does your host set up a route towards the next router and maintains
> it if the topology data from the router changes ? If yes I would say
>  it's a primitive router too. If no, it's not.
>
>>> If the node just use DHCP or similar protocols to get it's
>>> address without being modified to work with the MANET, it's no
>>> router
> (and don't
>> What if the host does not?  Or, do you mean to say that this
>> discussion is a way to legislate that all hosts must use DHCP?
> I don't think I ever said this. I just presented an example that the
> address model is not necessary for running a node in a MANET that use
> the autoconf address model.
>
>> The autoconf model for getting addresses doesn't exist. I sure hope
>> it isn't the only way to get an address.
>>
>> But suppose at some point there is an autoconf.exe. It should be a
>>  way for a host to get an address. Its connection to the MANET
>> would, presumably allow it to use this address.  Or, do you mean to
>> say that "address allocation" == "connection"?
> I don't see any reason why an autoconfiguration protocol developed by
> this group would only run on interfaces of routers.
>
>> main() { system ("get_address"); if (routing) fail();   /* My
>> compact routing code */ }
>>
>> Am I a router?
> I don't see any routing code of a routing protocol. But I don't see
> your problem too.
>
>> It's necessary for hosts to adhere to the considerations detailed
>> in the address model document.  I'm not sure if this is the same as
>> "using" it.
>> This is a political argument not based on the needs of the
>> addressability, connectivity, or goals of making an ad hoc network.
>> Insofar as you may be nonetheless correct, I begin to believe that
>> I have zero insight into the technical goals of the discussion.
>>
> I think the problem you stated is that people can say "the title says
> it's only for routers, so it is not enough for my usecase and I need
> something different".
>
> If we not change the title we might get "the title says it's for all
> nodes, but I cannot force my users to install a special interface
> configuration on their smartphones, so I need something different."
>
> There are nodes in MANET that are a grey area between host and
> router. Because of this we cannot make a clear statement on what
> nodes the autoconf address model should be used.
>
> Most of the WG seems to think it's better to restrict the scope a
> little bit more and let people use it for other things than the
> defined scope if they think it's right (at least that's how I
> understand the consensus of the group).
>
> Henning Rogge -- Diplom-Informatiker Henning Rogge ,
> Fraunhofer-Institut für Kommunikation, Informationsverarbeitung und
> Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Straße 20,
> 53343 Wachtberg, Germany Telefon +49 228 9435-961,   Fax +49 228 9435
> 685 mailto:[email-masked]
> <mailto:[email-masked]>
> http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487
> C67C 55EC CFE0
>
> list [email-masked] <mailto:[email-masked]>

---

From: Teco Boot <[email-masked]>
Date: Thu, 5 Aug 2010 14:23:25 +0200

Alex,

Again, I don't think this mail helps.
Nevertheless, another attempt. 

> Hmmm the rfc1812 title says "Reqs for IPv4 Routers" (not hosts)...

Your question was on routers. So RFC 1812 applies.
Longest match also applies to hosts. RFC 1122 starts with "best next
hop". Then, we had VLSM and CIDR.
All we ask, do a little research yourself and don't bother us.

> To me that reads that if a device has a single interface then it can't

Hmm. You quote from "2.2.8 Notable Oddities".
And it is a "should".
One way to circumvent is sending an icmp redirect, so next packets are send
directly to a better gateway.
More important: ask Fred himself on this. He worked on point-to-multipoint,
which works similar to what MANET routers do.

Appendix C (15) discuss future directions with "Multiple logical (sub)nets 
on the same wire." Thats where we are.

Also, the "lolly-pop router" or "router on a stick" are well known by now.
Isn't MIP HA an example?

So yes, a RFC1812-bis should use other wording.

> connectivity properties, one wouldn't say that a MANET Router is an

See previous remark on future directions.

Regards, Teco

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 05 Aug 2010 10:33:17 -0700

Hello Teco,

Comments below.

> Has this to do with our discussion?

AODV often connects an ad hoc network with
100% P2P links.  Are networks using AODV out of
scope?

> Can you come up with something other than p2p?

For what purpose?

> Then, what is in the routing table?

Whatever the host puts there.

> And what mechanism takes care?

Promiscuous mode can work, along with
other approaches.

> I still wonder how two hosts with off-link prefixes on same link can

802.11 doesn't care about prefixes.  What's
the problem?

> Data plane populating routing table ??

Not unusual.  Even DSR did this.

> What about uni-directional link test ??

Life is hard, and then we die.

> Please do so, previous one frightened me.

Fear naught.

> Refs are OK. Or describe one.

Your bait is lovely, but the adult in me
demands that I not go there just now.

> host and router, and the exact borderlines.

Or not, because I'm out of time and don't see
much reward.

Check.

> hosts have off-link prefixes?

You're stuck on prefixes.  It's a nasty
affliction, but very widespread.

> If there are protocols for such (and done in

This paragraph is full of holes.
First, you have declared nodes using BGP to
not be routers because BGP is not clean.

Second, hosts don't advertise _anything_ as
"part of the topology".

Third, routing complexity arises from quite
a few sources.  Need I mention "policy"?

Fourth, a router can route without running
any routing protocol.  Of course such a
device would be quite cumbersome to deploy
in the Internet, requiring human intervention
to adapt to changes.  But, as one tiny example,
this is exactly how I first tested Mobile IP.

Sometimes I'm not sure if you're serious when
making these assertions.

> So one could say we do not comply to RFC5942. Luckily, RFC5942 is for

I'll be just as happy not to go there at all.

> IMHO mix data plane and routing control plane is bad.

IP is bad?

There are numerous counterexamples.  For instance,
many liveness strategies readily utilize information
about data plane traffic (instead of, say, keepalives).

Again I am left wondering if you are tweaking me.

> are reachable via this interface. I call this routing.

I call it chocolate syrup.  Which is approximately
equally valid until we know what "it" is.

> Indeed. But it is quite dark for hosts, using this addressing model.

Teco, I can't really go on with this.  Of course
routing enlightens.  Providing valid information
is always enlightening (as opposed to, say, some
discussions in this thread).  You want to say
that X is a router, even if it MUST NEVER forward
any packets.  I think this is nonsense, pure and
simple.  Maybe _also_ sophistry, and maybe _also_
a waste of time due to lack of entertainment value.

> You disagreed with title change.

Do I _really_ have to unwind this thread for you?
I was responding to _your_ digression.

> I expect some argumentation. I did't see such.

Please look again.  Or I will save you the trouble:
i) hosts must obey the considerations in the draft
ii) [autoconf] producing a protocol that does not
     enable hosts to get addresses is plain silly.
 From these basic (invisible to you?) statements on
my part, we started traveling through the twilight
zone where routers don't forward packets and,
as a sort of very strange converse, P2P route
table entries get no respect even though ALL
manet routing protocols use them.

Traveling through this twilight zone, many people
in this group have acquired an ability to profess
that it's easier to configure routers than hosts,
regardless of 30 years of evidence to the contrary.

You might very well rightfully ask why I even
try to make any correction to the situation.
I know I am asking myself that question.

> forward packets.

When some say routers, they mean boxes with multiple
interfaces.  When some say routers, they include boxes
that MUST NEVER forward packets.  When some say routers,
they mean <... ding!  time's up!  game over ...>

> The intention is that routing protocols

Routers don't understand anything.  They're
machines, operating as programmed.  Oh, you
meant that a routing protocol is a program
of higher complexity than <... what? ...>.
Of course it's far more complex
than {} [{} == <null set>].

> But how can a host without on-link addresses populate the router

Here's my challenge to you.  Find a grad student
in networking who could NOT figure this out.
Of course, I am assuming that you do NOT mean what
you stated -- namely that the host must populate
the router's routing table.

If somehow the authors of 5942 have legislated that
hosts cannot transmit packets over wireless interfaces
with legal IP addresses, I send my regrets but I can't
fight that battle right now.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 05 Aug 2010 10:57:51 -0700

Hello Henning,

Comments/follow-up below...

> router too. If no, it's not.

What if it treats a particular route table
entry as a point-to-point link?  What if it
treats a particular route table entry as a
default route?  What if it hears a RA
message from a neighbor?

Seems to me we're having to bend over backwards
to call things "routers" in order to justify
making a wrong name for the document.

> Yes, you CAN use it... but you don't need to.

I'm glad to hear that.  But some hosts are still going
to have to abide by the autoconf addressing model, unless
unnecessary restrictions are put into place.  Changing the
name of the document, it seems to me, increases the danger
that these unnecessary restrictions _will_ be enacted.

>>  ...  suppose at some point there is an autoconf.exe.

> group would only run on interfaces of routers.

I'm glad to hear that.  So why make the restriction on
the document name??

> I don't see any routing code of a routing protocol. But I don't see your

I'm sorry you don't like my routing code.
Wasn't it claimed that a node can be a router
even if it always advertised  willingness  ==  0?

My problem is that in order to justify the restrictive
title, some people are bending over backwards to call
darned near anything a router.

> only for routers, so it is not enough for my usecase and I need something

_my_ usecase??  My usecase is that hosts should be
able to get addresses.  Do you think this is a
corner case?

> their smartphones, so I need something different."

Using this argument, we must immediately
destroy the great majority of IETF protocol
specifications.

> of this we cannot make a clear statement on what nodes the autoconf address

As far as I can recall, no one has made ANY nonpolitical
argument to indicate why hosts do not adhere to the addressing
model for [autoconf].  Do you remember any?

> think it's right (at least that's how I understand the consensus of the

I still think it's silly to make an [autoconf] protocol
that is prohibited for use by hosts.  Of course, any host
that wanted to use it would have to actually execute the
code -- isn't that a tautology?  So the smartphone point
has absolutely zero force in making this determination.

I do not understand the consensus of the group.  I only
speak for myself, and I'm honestly trying to see if there
is even an iota of technical justification for this change.
I might be wrong!  But until you or someone enlightens me I'll
still need to try to understand the relevance of your points.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 05 Aug 2010 15:16:52 -0700

Hello Emmanuel,

> consider the question "what is the definition of a host?". It seems to
> me that the devices we are aiming to configure are typically capable of
> things that hosts can't do (including, for instance, forwarding traffic
> on behalf of other devices, if necessary).

I don't think so.  If a device is a host and not
a router, it shouldn't be forwarding packets.

I'm sure that there are going to be non-routing
hosts in wireless ad hoc networks.  From previous
design work, I know that it is absolutely straightforward
to allow a host to request an address and get one (if
available).  You might check [from year 2001]:
	www.cs.ucsb.edu/~ebelding/txt/autoconf.txt
We seemed to know more on average in 2001, than has
been displayed here lately in the autoconf WG.  A node
does NOT have to forward packets to request an address!

>   "hosts are considered to be connected to a MANET only through
> a router, and thus, the MANET can be considered as comprising of only
> routers".

Do you _really_ want to exclude hosts from your network?
Where will the applications reside?  Hmmm... a network without
hosts...  Seems like a niche market.  But, ad hoc networks
are still a niche market, so this would be a niche niche
market.  <hmmm, sounds like Monty Python's knights...>

> configuring routers. Which lead us to where we are now.

When was this rough consensus?  Do you mean in Maastricht?
Or, before?  If the latter, I surely missed it.

Regards,
Charlie P.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 6 Aug 2010 17:53:03 +0200

> market.  <hmmm, sounds like Monty Python's knights...>

User applications (regular user applications) reside on hosts. Hosts are accessing the network by way of being connected to (i.e. one IP hop away from) a router. 

The connectivity between a host and a router is a "classic IP link", and there are already excellent protocols in existence for managing also autoconfiguration of addresses for hosts on classic IP links. 

The connectivity between routers is.....who knows? Maybe a MANET, maybe an OSPF network, maybe an ISIS network, and maybe links between routers have "undetermined connectivity properties" -- or not, they may be of NBMA or P2P or telepathic nature. However, that's a matter for routers to figure out and manage; hosts are exposed to a classic IP link and are isolated by an IP hop from any specific connectivity properties of the connectivity/links between routers.

Of course, there *may* be applications (for example, the routing demon) running on routers and exposed to the specific connectivity properties of the connectivity/links between routers. These, and only these (non-user) applications should be sufficiently aware of these properties to operate correctly. User-applications reside on hosts, separated by an IP hop from any "strangeness" between routers, and exposed to well-defined properties of a classic IP link.

That is analogous to how the Internet otherwise work.

> Or, before?  If the latter, I surely missed it.

Now, you made me go look it up exactly...

This particular point was discussed - at length - at IETF'67 in 2006 in San Diego, where it received (in my recollection) wide consensus; in part because of its analogy with the "regular Internet".

Sincerely yours,

Thomas

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 06 Aug 2010 09:56:40 -0700

Hello Thomas,

I said:

>> Where will the applications reside?

You said:

> User applications (regular user applications) reside on hosts. Hosts are
> accessing the network by way of being connected to (i.e. one IP hop away
> from) a router.

Of course I do not have a problem with running applications
on MANET routers.  I have proposed this for many years --
and in fact I do not in any way require that the applications
reside on hosts that are one hop away from a router.

My question was partly in jest -- but I do fully
expect that non-routing hosts will be found in many
or perhaps even most ad hoc networks.  For instance,
we will have sensor fields and transmit-only data
aggregators (both of which do not need to be routers,
but are likely to need addresses).  I keep thinking
this is totally obvious!

> The connectivity between a host and a router is a "classic IP link",
> and there are already excellent protocols in existence for managing
> also autoconfiguration of addresses for hosts on classic IP links.

My objection has been to disqualify non-routing hosts from receiving
addresses by way of an [autoconf] protocol.  There are of course known
protocols (excellent or not, does not matter here) for configuring
"classic hosts" on "classic IP links".  I reckon we mean the same
thing by those terms.

My point is that there are almost certainly going to be non-routing
hosts in <networks whose connectivity is established by MANET routers.>
I would have just said "MANETs", but now we have so little agreement
that we don't even know what a MANET is any more.

> The connectivity between routers is.....who knows? Maybe a MANET,
> maybe an OSPF network, maybe an ISIS network, and maybe links between
> routers have "undetermined connectivity properties" -- or not, they
> may be of NBMA or P2P or telepathic nature. However, that's a matter
> for routers to figure out and manage; hosts are exposed to a classic
> IP link and are isolated by an IP hop from any specific connectivity
> properties of the connectivity/links between routers.

Here I have to disagree.  A host may have an 802.11 link to a router,
and be subject to every single last problem of indeterminate range,
interference, link-local ambiguity, and the other concepts which have
proved so difficult for [autoconf] to resolve (regardless of so much
reputable research available).

And, moreover, it's not up to the "routers".  It's up to "us",
because we're designing the routers (at least in [manet] wg,
not in [autoconf]).  Moreover, if a MANET router can work better
by transacting new protocol with a host, then (a) the host may
then considered to be something besides a "classic host", and
(b) why not?  Let's figure it out.  But this does NOT mean that
a network of the abovementioned variety has to REQUIRE changes
to classic hosts; as an example, NEMO has made a lot of changes
but still allows "classic" hosts to reside on mobile networks.
Our situation is a bit different, insofar as mobile wireless hosts
still must pay due respect to the realities of wireless.

> Of course, there *may* be applications (for example, the routing demon)
> running on routers and exposed to the specific connectivity properties
> of the connectivity/links between routers. These, and only these
> (non-user) applications should be sufficiently aware of these properties
> to operate correctly. User-applications reside on hosts, separated by
> an IP hop from any "strangeness" between routers, and exposed to
> well-defined properties of a classic IP link.

I also disagree with this.  Numerous studies have shown that
applications can benefit from knowledge of bit-error rate,
link capacity, jitter, and so on.  Of course we'd prefer that
applications not have to pay attention to CDMA vs. 802.11,
etc.  Nevertheless, I am sure that in a face-to-face meeting
on this subject we would quickly find that we are in substantially
complete agreement.

...

> This particular point was discussed - at length - at IETF'67 in 2006 in
> San Diego, where it received (in my recollection) wide consensus; in part
> because of its analogy with the "regular Internet".

Surely, "configuring" routers and hosts should be
done differently.  This does NOT imply:
(a) hosts should be barred from using the address
     allocation protocol established for MANET routers, or
(b) hosts should run useless router code in order to
     make use of said address allocation protocol, or
(c) the [autoconf] address allocation protocol design
     should proceed on the assumption that non-routing
     hosts are out of scope.

Regards,
Charlie P.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 6 Aug 2010 19:22:32 +0200

Charlie,

You suggest a face-to-face meeting. As you know I will be in your neck of the woods next week, so let's discuss, then ...

Wg-chair-hat-on: 

If we do that, we do owe it to the wg to report both the arguments and the outcome of the discussions here on the list, as I believe that both are valuable for the wg. Although (still wearing that hat) I would very much like for as much of the discussions to be in public (ie on the list)....

Wg-chair-hat-off:

I'll respond in more details later, but I have suitcases to pack ...

-- 
Thomas Clausen
http://www.thomasclausen.org/

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 9 Aug 2010 19:29:30 +0200

Hi Charlie,

On Fri, Aug 6, 2010 at 6:56 PM, Charles E. Perkins <
[email-masked]> wrote:
> done differently.

We are in agreement here ;)

>  This does NOT imply:

we are also in agreement here.

>    make use of said address allocation protocol, or

same as above: violent agreement.

>    should proceed on the assumption that non-routing

here on the other hand, I think I disagree. It is a priori more difficult to
provide autoconfiguration for nodes which have heterogeneous capabilities,
rather than to provide an autoconfiguration solution for nodes which have
homogeneous capabilities -- especially if nodes all have the most
capabilities, i.e. they are all routers.

So at this point, either (i) there is priori art that
provides autoconfiguration for nodes which have heterogeneous capabilities,
and then let's consider it, or (ii) there is no prior art and then let's do
the easiest step first: focus on providing an autoconfiguration solution for
routers. Provided that your points (a) and (b) are agreed on, does this make
sense to you?

I remember you mentioning that there is indeed prior art. The way I
understand it, this prior art is something that the effort stemming from
second item in the proposed charter should seriously consider.

regards,

Emmanuel

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 09 Aug 2010 10:55:02 -0700

Hello Emmanuel,

To answer your implied request:

On 8/9/2010 10:29 AM, Emmanuel Baccelli wrote:

> here on the other hand, I think I disagree.  ...

> provides autoconfiguration for nodes which have heterogeneous
> capabilities, and then let's consider it, ...

> I remember you mentioning that there is indeed prior art.

Here is a link to prior art, which I mentioned
in a previous email to you on this list:

>  .......         You might check [from year 2001]:

What do you think about that?

But, maybe more to the point, I know I have seen a
good half-dozen distinct approaches to this problem.
They have various advantages and disadvantages, but
they share one trait:
- they all provide addresses for both forwarding
   nodes and non-forwarding nodes.

Right now I can't think of a good approach that
actually does disqualify hosts.

Of course it's not a democracy, and the other authors
are not in the IETF.  I guess they don't like to have
five-year debates about what is a router and what is
a link.  But they are very sharp people.  I would have
thought that their insight, experience, development,
and testing might count for _something_.

Regards,
Charlie P.

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 11 Aug 2010 13:51:25 +0200

Hi Charlie,

> good half-dozen distinct approaches to this problem.

I think this approach is interesting and should definitely be considered
with the half-dozen others you hint at, in parallel of the DHCP-based
approach that is aimed at. As far as I understood, this is the spirit of the
second item in the proposed charter.

Emmanuel

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 11 Aug 2010 14:01:17 +0200

Hi Ryuji,

I support the proposed changes, although I'm not particularly keen on
altering the title (actually I have not noticed anybody who is, I just
noticed some people who oppose it ;) and I would prefer to simply skip the
last sentence about EUI-64.

Cheers

Emmanuel