Subject: [manet] I-D Action: draft-ietf-manet-aodvv2-14.txt

From: [email-masked]
Date: Tue, 05 Apr 2016 03:19:03 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobile Ad-hoc Networks of the IETF.

        Title           : Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing
        Authors         : Charles E. Perkins
                          Stan Ratliff
                          John Dowdell
                          Lotte Steenbrink
                          Victoria Mercieca
	Filename        : draft-ietf-manet-aodvv2-14.txt
	Pages           : 80
	Date            : 2016-04-05

Abstract:
   The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing
   protocol is intended for use by mobile routers in wireless, multihop
   networks.  AODVv2 determines unicast routes among AODVv2 routers
   within the network in an on-demand fashion.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-aodvv2/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-manet-aodvv2-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-aodvv2-14

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Lotte Steenbrink <[email-masked]>
Date: Tue, 5 Apr 2016 12:53:38 +0200

Hi all,
just a quick summary of what is and what isn’t included in this update of the draft:

DONE:
————
* All JWD! comments (i.e. the critical ones) are resolved
* Out of 90 JWD and JWD! comments, 61 are resolved
* The revised security considerations [1] were added (with the TODOs commented out)
* The following TODO from [1] was resolved: 
   "This description MUST
   include the reasons it was either unreasonable or out of scope to
   attempt to avoid these denial of service attacks."
* Section 9 now contains a statement that AODVv2 doesn’t support RREQs for prefixes, I hope that clears things up for Thomas.

TO DO:
———— 
* Most notable of the 29 JWDs that are yet to be resolved:
	+ (is there some table that lists routes that are being waited on? JWD) We decided to add a separate 
           RREP table that lists them and I’ve volunteered to write text for that, but we’re currently discussing if/how
           we might solve this without adding yet another table.

	+ We’re currently discussing the approaching the limit thing. (i.e.
	   (There is no defined behavior here. Approaching the limit? Section 6.5 outlines which messages are more important but now how to decide to allow them to be transmitted or not. JWD 
	  and
	  (The undefined approaching the limit thing again JWD) etc
           We’ve already clarified the wording regarding what the limit is and how to prioritize the message types, 
           what’s left is to define what „approaching“ means (and whether we need to talk about approaching rather than
           just saying „here’s what to do when you actually hit the limit").

   	+ (I don’t want to spam the list with a comprehensive list of all of them, but if you’re interested in seeing them,
           please do say so and I’ll send my copy of Justin’s review containing all TODOs and DONEs to the list)
* some TODOs in security considerations (see [1])
* since we're waiting for Chris’ feedback regarding the revised 5444 multiplexer wording, that hasn’t changed yet.

More details can be found in Appendix A.  AODVv2 Draft Updates, as well as the diff, of course.

Best regards,
Lotte

[1] Re: [manet] AODVv2: Security considerations update https://www.ietf.org/mail-archive/web/manet/current/msg18458.html

> Am 05.04.2016 um 12:19 schrieb [email-masked]:
> 
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: [email-masked]
Date: Tue, 5 Apr 2016 20:07:55 +0200

Lotte,

Thank you for this update. An impressive amount of changes to the document, according to RFCdiff, and as I can see from your mail that there is much more to come, I hope that you forgive me for not jumping at a blow-by-blow review until a version which the authors themselves consider stable, is produced.

On the point of “much more to come", there have been quite a few comments raised by WG participants other than Mr. Dean and Chris  (such as by myself, but not only) — some of which intersect some of the below, and for which I do not believe that a satisfactory resolution has been developed, presented to the WG, and confirmed.

In which revision of the I-D do you plan on addressing those?

Best,

Thomas

> On Apr 5, 2016, at 12:53, Lotte Steenbrink <[email-masked]> wrote:
> 
> Hi all,
> [1] Re: [manet] AODVv2: Security considerations update https://www.ietf.org/mail-archive/web/manet/current/msg18458.html <https://www.ietf.org/mail-archive/web/manet/current/msg18458.html>
> 
> 
>> Am 05.04.2016 um 12:19 schrieb [email-masked] <mailto:[email-masked]>:
>> 
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-manet-aodvv2/ <https://datatracker.ietf.org/doc/draft-ietf-manet-aodvv2/>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>

---

From: Lotte Steenbrink <[email-masked]>
Date: Thu, 7 Apr 2016 16:49:46 +0200

Hi Thomas,

> Am 05.04.2016 um 20:07 schrieb [email-masked]:
> 
> Lotte,
> 
> Thank you for this update. An impressive amount of changes to the document, according to RFCdiff, and as I can see from your mail that there is much more to come,

Thanks! I’m glad you’re seeing the progress we’ve made. 

> I hope that you forgive me for not jumping at a blow-by-blow review until a version which the authors themselves consider stable, is produced.
> 

I’m not quite sure which comments exactly you are referring to? Your last comments that come to mind are the ones in these threads:

https://www.ietf.org/mail-archive/web/manet/current/msg18055.html <https://www.ietf.org/mail-archive/web/manet/current/msg18055.html>
https://www.ietf.org/mail-archive/web/manet/current/msg18639.html <https://www.ietf.org/mail-archive/web/manet/current/msg18639.html>

You’ve announced to go through the former in your last response to the latter, but as far as I can see you haven’t gotten round to doing that and a lot of points you’ve brought up have sparked ongoing discussions, so I’ve marked most of your comments as “pending– still in discussion” in my mind. 
Regarding the points you brought up that aren’t affected by this:

* Metrics– we’ve had discussions about this many moons ago with authors on both sides of the fence. Unfortunately I can’t remember the counter arguments, and I’m still looking for records of this conversation… I’ll get back to you when I’ve found out more.
* Prefixes & Gateways: I’ve added a sentence to clarify that AODVv2 doesn’t do RREQs for gateways, I hop that helps?

> In which revision of the I-D do you plan on addressing those?

If the discussions reach a conclusion by then, I’d be glad to have them addressed by the next revision.

Best regards,
Lotte

> Best,
> 
> Thomas
> 
> 
> 
>> On Apr 5, 2016, at 12:53, Lotte Steenbrink <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi all,
>>> https://tools.ietf.org/html/draft-ietf-manet-aodvv2-14 <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-14>
>>>

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 7 Apr 2016 17:55:24 +0100

[This time from a subscribed address.]

You say you've added a sentence saying AODVv2 doesn't do RREQs for gateways. What should have happened is a discussion on this list as to why? is that hard? does anyone have a clever idea to make it not hard? does anyone need that functionality? and so on.

For example, here's something that superficially looks like it might work. Does it, or does it introduce new problems? I don't know. But this, and likely better ideas, just haven't had discussion here - and I fear that the people who might have the better ideas have departed unheard.

So, a router wants a route to a.b.c.d, and sends an RREQ for that (/32, or simply omit). Of course any router directly serving that address just replies. But a router that is serving a.0.0.0/8 could reply with that address. The originating router of course would use standard IP maximum prefix length rules. Does that work? Does it help anyone? Could a router reply a.b.c.d/32 and a.0.0.0/8 in one RREP? Or could it be allowed to reply a.b.c.d/8 as a shorthand? And why can't a router request a.b.0.0/16 - and possibly get an a.0.0.0/8 reply?

Answers to all of those is "I don't know".  But we should have been having those discussions.

-- 
Christopher Dearlove
[email-masked]

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)
> On 7 Apr 2016, at 15:49, Lotte Steenbrink <[email-masked]> wrote:
> 
> Hi Thomas,
> 
> https://www.ietf.org/mail-archive/web/manet/current/msg18055.html
> https://www.ietf.org/mail-archive/web/manet/current/msg18639.html
>

---

From: Victoria Mercieca <[email-masked]>
Date: Thu, 7 Apr 2016 18:49:37 +0100

Hi Christopher,

On 7 Apr 2016 1:55 pm, "Christopher Dearlove" <
[email-masked]> wrote:
> You say you've added a sentence saying AODVv2 doesn't do RREQs for
gateways. What should have happened is a discussion on this list as to why?
is that hard? does anyone have a clever idea to make it not hard? does
anyone need that functionality? and so on.
>
> For example, here's something that superficially looks like it might
work. Does it, or does it introduce new problems? I don't know. But this,
and likely better ideas, just haven't had discussion here - and I fear that
the people who might have the better ideas have departed unheard.
>
> So, a router wants a route to a.b.c.d, and sends an RREQ for that (/32,
or simply omit). Of course any router directly serving that address just
replies. But a router that is serving a.0.0.0/8 could reply with that
address. The originating router of course would use standard IP maximum
prefix length rules. Does that work? Does it help anyone? Could a router
reply a.b.c.d/32 and a.0.0.0/8 in one RREP? Or could it be allowed to reply
a.b.c.d/8 as a shorthand?

This is exactly what it does (based on the router client entry
corresponding to TargAddr, e.g if router client entry is a.0.0.0/8, then
the RREP contains a.b.c.d/8). Everyone receiving the RREP can then install
the route to a.0.0.0/8 and therefore avoid a separate RREQ for (as an
example) a.b.c.e in future. Similarly an RREQ contains the prefix length
associated with the router client entry configured for OrigAddr, and
routers processing the RREQ learn the route to OrigAddrs prefix.

But you can't intentionally send a RREQ for a prefix because the RREQ is
created when there's a packet to send, you know the destination address not
the prefix associated with it, so TargAddr is a.b.c.d/32. But even so, you
do end up learning a route to a prefix, if TargAddr is part of a router
client entry which is a prefix.

Kind regards,
Victoria.

> And why can't a router request a.b.0.0/16 - and possibly get an a.0.0.0/8
reply?
>>> Thank you for this update. An impressive amount of changes to the
document, according to RFCdiff, and as I can see from your mail that there
is much more to come,
>>> I hope that you forgive me for not jumping at a blow-by-blow review
until a version which the authors themselves consider stable, is produced.
>>>
>>> On the point of “much more to come", there have been quite a few
comments raised by WG participants other than Mr. Dean and Chris  (such as
by myself, but not only) — some of which intersect some of the below, and
for which I do not believe that a satisfactory resolution has been
developed, presented to the WG, and confirmed.
>>
>>
>> I’m not quite sure which comments exactly you are referring to? Your
last comments that come to mind are the ones in these threads:
>> You’ve announced to go through the former in your last response to the
latter, but as far as I can see you haven’t gotten round to doing that and
a lot of points you’ve brought up have sparked ongoing discussions, so I’ve
marked most of your comments as “pending– still in discussion” in my mind.
>> * Metrics– we’ve had discussions about this many moons ago with authors
on both sides of the fence. Unfortunately I can’t remember the counter
arguments, and I’m still looking for records of this conversation… I’ll get
back to you when I’ve found out more.
>> * Prefixes & Gateways: I’ve added a sentence to clarify that AODVv2
doesn’t do RREQs for gateways, I hop that helps?
>>>> * Section 9 now contains a statement that AODVv2 doesn’t support RREQs
for prefixes, I hope that clears things up for Thomas.
>>>>            RREP table that lists them and I’ve volunteered to write
text for that, but we’re currently discussing if/how
>>>>    (There is no defined behavior here. Approaching the limit? Section
6.5 outlines which messages are more important but now how to decide to
allow them to be transmitted or not. JWD
>>>>            We’ve already clarified the wording regarding what the
limit is and how to prioritize the message types,
>>>>            what’s left is to define what „approaching“ means (and
whether we need to talk about approaching rather than
>>>>     + (I don’t want to spam the list with a comprehensive list of all
of them, but if you’re interested in seeing them,
>>>>            please do say so and I’ll send my copy of Justin’s review
containing all TODOs and DONEs to the list)
>>>> * since we're waiting for Chris’ feedback regarding the revised 5444
multiplexer wording, that hasn’t changed yet.
>>>> [1] Re: [manet] AODVv2: Security considerations update
https://www.ietf.org/mail-archive/web/manet/current/msg18458.html

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 7 Apr 2016 21:19:30 +0100

Thanks, that addresses most of the points I made.

Assuming that is that a packet reception for forwarding is the only option you choose to allow. It's perfectly reasonable for an implementation to think "wouldn't it be sensible to learn about a gateway now for various reasons?".  Yes, there's the problem of which subnet to look for (0.0.0.0/0 or something smaller). Yes, I can imagine you don't want to define this now - unless of course someone in the WG says they really want it. But I would say, don't close the door on it, even if not doing it now.

(There are other possibilities that might be useful one day. An RREQ that looks for more than one address for example - you could trade latency and overhead by combining RREQs.)

> On 7 Apr 2016, at 18:49, Victoria Mercieca <[email-masked]> wrote:
> 
> Hi Christopher,
> 
> On 7 Apr 2016 1:55 pm, "Christopher Dearlove" <[email-masked]> wrote:
> >
> > So, a router wants a route to a.b.c.d, and sends an RREQ for that (/32, or simply omit). Of course any router directly serving that address just replies. But a router that is serving a.0.0.0/8 could reply with that address. The originating router of course would use standard IP maximum prefix length rules. Does that work? Does it help anyone? Could a router reply a.b.c.d/32 and a.0.0.0/8 in one RREP? Or could it be allowed to reply a.b.c.d/8 as a shorthand?
> 
> This is exactly what it does (based on the router client entry corresponding to TargAddr, e.g if router client entry is a.0.0.0/8, then the RREP contains a.b.c.d/8). Everyone receiving the RREP can then install the route to a.0.0.0/8 and therefore avoid a separate RREQ for (as an example) a.b.c.e in future. Similarly an RREQ contains the prefix length associated with the router client entry configured for OrigAddr, and routers processing the RREQ learn the route to OrigAddrs prefix.
> 
> But you can't intentionally send a RREQ for a prefix because the RREQ is created when there's a packet to send, you know the destination address not the prefix associated with it, so TargAddr is a.b.c.d/32. But even so, you do end up learning a route to a prefix, if TargAddr is part of a router client entry which is a prefix.
> 
> Kind regards,
> Victoria.
> 
> > And why can't a router request a.b.0.0/16 - and possibly get an a.0.0.0/8 reply?
> >

---

From: [email-masked]
Date: Wed, 20 Apr 2016 11:02:45 +0200

Hi,

Looking back over issues that I have raised, I am not sure that I saw any replies to this, so I went looking in the I-D for some clarification and some follow-up questions.

First, section 9 contains this throw-away comment:

	   Configuring the ENAR as a default router is outside the scope of this
	   specification.

Either I do not understand what you mean by “…as a default router…” or there’s a layer of complexity (that I can guess at) which you’re not telling, but which really should be called out. 

My guess would be, that a router inside the MANET will need to communicate to (say) google, you would do a Route Discovery (RREQ/RREP) cycle and the ENAR would return a route to  2a00:1450:4007:80e::2003 — and then when you 30s later need to communicate to (say) Facebook.com you would do a Route Discovery (RREQ/RREP) cycle and the ENAR would return a route to 2a03:2880:20:4f22:face:b00c::25de. 

I.e. the “…as default router…” means that you do not know of any way of making it work such that the ENER an reply, to the first of these two, with simply 0::0/0, and then have the routers in the MANET install a route via the ENAR to destinations not inside the MANET?

What I am getting at here is, that if I understand correctly then connectivity to “the Internet” is very, very inefficiently supported — or, actually, more precisely that connectivity to any “external network which can only be captured by a prefix which also includes destinations inside the MANET” is very inefficiently supported (because you cannot install prefix routes to such a network).

If I am understanding this correctly, then it deserves more elaboration than the throw-away mention at the end of Section 9, cited above, and certainly this paragraph from the applicability statement needs to correctly reflect it:

   AODVv2 is designed for stub or disconnected mobile ad hoc networks,
   i.e., non-transit networks or those not connected to the internet.
   AODVv2 can, however, be configured to perform gateway functions when
   attached to external networks, as discussed in Section 9.

Second, section 7.1 specifies for RREQs:

	   AddressList
		      Contains OrigAddr and TargAddr, the source and destination
		      addresses of the IP packet for which a route is requested.
		      OrigAddr and TargAddr MUST be routable unicast addresses.

Again, if I have understood correctly, if a router has 255 hosts attached (say a /56), each of which need to communicate with a server, then the router must end up generating 255 RREQ/RREP cycles, even though it may already have an entry for the IP address for the server?

The reason why I speculate that this is so is, that RREQ forwarding installs the “reverse route” towards the source, and if OrigAddr is "the source addresses of the IP packet for which a route is requested” address, i.e., there is no way for the RREQ to request a route to the server “at once” on behalf of "the entire /56”  behind it?

Again, if I am understanding this correctly, then it deserves a bit more elaboration, notably a framing of the cases discussed in the above, and a modulation of the statement from the applicability statement that:

	AODVv2 can, however, be configured to perform gateway functions when
   	attached to external networks, as discussed in 
	Section 9.

Capturing these limitations of gateway functionality?

The same, probably, also applies in the opposite direction, i.e., in case a single “source” needs to communicate with many or all of a /56, behind a router?

Best,

Thomas

> On 07 Apr 2016, at 23:11, Thomas Heide Clausen <[email-masked]> wrote:
> 
> On this whole gateway issue, I am disturbed...most routers would have one-or-multiple /64-or-shorter, one per non-Manet link (w/ hosts hanging off) delegated to them, and not just a single /128.
> 
> Needing to communicate with many-to-all hosts on a link is not uncommon (if the hosts are, e.g., environmental controls in the same room), and the ability to "get the whole prefix advertised at once" send an RREQ for the whole prefix - specifically, for not 
> 
> Sent from my iPad
> 
> On 07 Apr 2016, at 22:19, Christopher Dearlove <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> [email-masked] <mailto:[email-masked]> (iPhone)
>> [email-masked] <mailto:[email-masked]> (home)
>> 
>> On 7 Apr 2016, at 18:49, Victoria Mercieca <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> Hi Christopher,
>>> 
>>> On 7 Apr 2016 1:55 pm, "Christopher Dearlove" <[email-masked] <mailto:[email-masked]>> wrote:
>>> >
>>> > [email-masked] <mailto:[email-masked]>
>>> >
>>> >
>>> >
>>> > --  
>>> > Christopher Dearlove
>>> > [email-masked] <mailto:[email-masked]> (iPhone)
>>> > [email-masked] <mailto:[email-masked]> (home)
>>> > On 7 Apr 2016, at 15:49, Lotte Steenbrink <[email-masked] <mailto:[email-masked]>> wrote:
>>> >
>>> >> Hi Thomas,
>>> >>
>>> >>> Am 05.04.2016 um 20:07 schrieb [email-masked] <mailto:[email-masked]>:
>>> >>>
>>> >>> Lotte,
>>> >>>
>>> >>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-aodvv2-14 <https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-aodvv2-14>
>>> >>>>>
>>> >>>>>
>>> >>>>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>>> >>>>>
>>> >>>>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>>> >>>>>
>>> > https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>_______________________________________________
>> manet mailing list

---

From: Victoria Mercieca <[email-masked]>
Date: Wed, 20 Apr 2016 10:50:11 +0100

Hi Thomas,

See comments in line...

On Wed, Apr 20, 2016 at 10:02 AM, <[email-masked]> wrote:

> Hi,
>
> Looking back over issues that I have raised, I am not sure that I saw any
> replies to this, so I went looking in the I-D for some clarification and
> some follow-up questions.
>
> *First, section 9 contains this throw-away comment:*
>
> Either I do not understand what you mean by “…as a default router…” or
> there’s a layer of complexity (that I can guess at) which you’re not
> telling, but which really should be called out.
>
> My guess would be, that a router inside the MANET will need to communicate
> to (say) google, you would do a Route Discovery (RREQ/RREP) cycle and the
> ENAR would return a route to  2a00:1450:4007:80e::2003 — and then when
> you 30s later need to communicate to (say) Facebook.com
> <http://facebook.com> you would do a Route Discovery (RREQ/RREP) cycle
> and the ENAR would return a route to 2a03:2880:20:4f22:face:b00c::25de.
>
> I.e. the “…as default router…” means that you do not know of any way of
> making it work such that the ENER an reply, to the first of these two, with
> simply 0::0/0, and then have the routers in the MANET install a route via
> the ENAR to destinations not inside the MANET?
>
> What I am getting at here is, that if I understand correctly then
> connectivity to “the Internet” is very, very inefficiently supported — or,
> actually, more precisely that connectivity to any “external network which
> can only be captured by a prefix which also includes destinations inside
> the MANET” is very inefficiently supported (because you cannot install
> prefix routes to such a network).
>
> If I am understanding this correctly, then it deserves more elaboration
> than the throw-away mention at the end of Section 9, cited above, and
> certainly this paragraph from the applicability statement needs to
> correctly reflect it:
>
> *Second, section 7.1 specifies for RREQs:*
>
>    AddressList
> Again, if I have understood correctly, if a router has 255 hosts attached
> (say a /56), each of which need to communicate with a server, then the
> router must end up generating 255 RREQ/RREP cycles, even though it may
> already have an entry for the IP address for the server?
>
>
No. While OrigAddr and TargAddr are the source and destination addresses of
the IP packet for which a route is requested, we also include in a RREQ the
prefix length for OrigAddr, which is the prefix length as seen in the
corresponding Router Client entry on RREQ_Gen. So, any routers receiving
the RREQ learn a route to the whole prefix.

This is what happens:
1) packet arrives e.g. from source 10.0.0.1 and to destination 20.0.0.2
2) router has no route to 20.0.0.2
3) router matches source address 10.0.0.0 to router client entry 10.0.0.0/8
(therefore will send a RREQ)
4) router creates RREQ using OrigAddr = 10.0.0.1 and OrigPrefixLen = 8.
5) receiving routers learn route to 10.0.0.0/8.

However, because initially you have this single IP packet with a specific
destination IP address, you can't intentionally send a RREQ for the whole
prefix associated with TargAddr. But the route you get back in a RREP has
TargAddr and TargPrefixLen (which corresponds to the router client entry at
RREP_Gen), which combined represents the route to the prefix TargAddr is
part of, which is what gets installed at each router receiving the RREP.

Perhaps this would be clearer, if instead of including the data packet's
source IP address as the OrigAddr in a RREQ, we used the corresponding
router client entry as OrigAddr? Step 4 above would become:
4) router creates RREQ using OrigAddr = 10.0.0.0 and OrigPrefixLen = 8.
Similarly for RREP and TargAddr.
Perhaps to make it completely clear, we could rename OrigAddr to OrigPrefix
in a RREQ, and TargAddr to TargPrefix in a RREP. So the RREQ contains
OrigPrefix, OrigPrefixLen and TargAddr. And the RREP contains OrigPrefix,
OrigPrefixLen, TargPrefix, TargPrefixLen.
What do you think of this suggestion?

This links in to the gateway question...
I think the ENAR could potentially respond to a route request for an
external address by sending a RREP containing the default route. It's
equivalent to the requested TargAddr being part of a router client entry
for a prefix on RREP_Gen. Using the current rules, the ENAR would attempt
to send a RREP with TargAddr set to match TargAddr in the RREQ, and
TargPrefixLen of 0. Even if the RREP contained TargAddr = 0.0.0.0 and
TargPrefixLen of 0, RREQ_Gen could still match this with the RREQ it had
sent and consider the route request fulfilled. Do you see a problem with
this? We would need to update the wording and the current use of Prefix
Length, since we currently interpret a prefix length of 0, and also the
omission of prefix length value, to mean the full address length.

Kind Regards,
Victoria.

The reason why I speculate that this is so is, that RREQ forwarding
> installs the “reverse route” towards the source, and if OrigAddr is "the
> *source* addresses of the IP packet for which a route is requested”
> address, i.e., there is no way for the RREQ to request a route to the
> server “at once” on behalf of "the entire /56”  behind it?
>
> Again, if I am understanding this correctly, then it deserves a bit more
> elaboration, notably a framing of the cases discussed in the above, and a
> modulation of the statement from the applicability statement that:
>
> The same, probably, also applies in the opposite direction, i.e., in case
> a single “source” needs to communicate with many or all of a /56, behind a
> router?
>
> Best,
>
> Thomas
>
>
> On this whole gateway issue, I am disturbed...most routers would have
> one-or-multiple /64-or-shorter, one per non-Manet link (w/ hosts hanging
> off) delegated to them, and not just a single /128.
>
> Needing to communicate with many-to-all hosts on a link is not uncommon
> (if the hosts are, e.g., environmental controls in the same room), and the
> ability to "get the whole prefix advertised at once" send an RREQ for the
> whole prefix - specifically, for not
>
> Sent from my iPad
>
> On 07 Apr 2016, at 22:19, Christopher Dearlove <
> Assuming that is that a packet reception for forwarding is the only option
> you choose to allow. It's perfectly reasonable for an implementation to
> think "wouldn't it be sensible to learn about a gateway now for various
> reasons?".  Yes, there's the problem of which subnet to look for (
> 0.0.0.0/0 or something smaller). Yes, I can imagine you don't want to
> define this now - unless of course someone in the WG says they really want
> it. But I would say, don't close the door on it, even if not doing it now.
>
> (There are other possibilities that might be useful one day. An RREQ that
> looks for more than one address for example - you could trade latency and
> overhead by combining RREQs.)
>
> --
> Christopher Dearlove
> >>>> * Section 9 now contains a statement that AODVv2 doesn’t support
> RREQs for prefixes, I hope that clears things up for Thomas.
> >>>>
> >>>> TO DO:
> >>>> ————

---

From: [email-masked]
Date: Wed, 20 Apr 2016 17:33:03 +0200

Victoria,

Apologies for the delayed reply, I had a business lunch, and then a bit of road to cover before I could sit down and type.

> On Apr 20, 2016, at 11:50, Victoria Mercieca <[email-masked]> wrote:
> 
> Hi Thomas,
> 
> See comments in line...
> 
> 
> On Wed, Apr 20, 2016 at 10:02 AM,  <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> My guess would be, that a router inside the MANET will need to communicate to (say) google, you would do a Route Discovery (RREQ/RREP) cycle and the ENAR would return a route to  2a00:1450:4007:80e::2003 — and then when you 30s later need to communicate to (say) Facebook.com <http://facebook.com/> you would do a Route Discovery (RREQ/RREP) cycle and the ENAR would return a route to 2a03:2880:20:4f22:face:b00c::25de. 
> 
> No. While OrigAddr and TargAddr are the source and destination addresses of the IP packet for which a route is requested, we also include in a RREQ the prefix length for OrigAddr, which is the prefix length as seen in the corresponding Router Client entry on RREQ_Gen. So, any routers receiving the RREQ learn a route to the whole prefix. 
> 

> 3) router matches source address 10.0.0.0 to router client entry 10.0.0.0/8 <http://10.0.0.0/8> (therefore will send a RREQ)
> 5) receiving routers learn route to 10.0.0.0/8 <http://10.0.0.0/8>.
> 

So that’s the good news — glad to read that, thank you for that explanation.

Now, why did that not jump out at me when I read through the document, either in a protocol overview sorta section, or in the “gateway to external networks” sorta section? That would be the sort that definitely should be called out.

> However, because initially you have this single IP packet with a specific destination IP address, you can't intentionally send a RREQ for the whole prefix associated with TargAddr. But the route you get back in a RREP has TargAddr and TargPrefixLen (which corresponds to the router client entry at RREP_Gen), which combined represents the route to the prefix TargAddr is part of, which is what gets installed at each router receiving the RREP.

I do not like that asymmetry, though, but that may be because I have IPv6 on my mind here: a host, which is sitting behind a router, will be on a link - with said link have a /64. If, by some magic, I know that I will need to talk to (more than one destination on) “that link”, then it’s somewhat counterintuitive to have to send an RREQ to a random address from within that link, hoping that the router will respond.
 
> Perhaps this would be clearer, if instead of including the data packet's source IP address as the OrigAddr in a RREQ, we used the corresponding router client entry as OrigAddr?

> Step 4 above would become:
> Perhaps to make it completely clear, we could rename OrigAddr to OrigPrefix in a RREQ, and TargAddr to TargPrefix in a RREP. So the RREQ contains OrigPrefix, OrigPrefixLen and TargAddr. And the RREP contains OrigPrefix, OrigPrefixLen, TargPrefix, TargPrefixLen.

If I understand correctly (the “Router Client” terminology remains extremely confusing), then the host (a /128) connected to a router with a link with a prefix (a p/64), is represented by an “entry” (p/64) in the router?. So you suggest to  send p/64 as OrigAddr in place of the /128 (in which case that likely should be OrigPrefix? 

That, at least, would make it a lot clearer what actually happens, especially in intermediate routers who install a reverse route back to the OrigAddr (OrigPrefix).

> This links in to the gateway question…

Well, in a sense, IPv6 makes the router “by default” a gateway to an external, non-/128 prefix, so … ;)

> I think the ENAR could potentially respond to a route request for an external address by sending a RREP containing the default route. It's equivalent to the requested TargAddr being part of a router client entry for a prefix on RREP_Gen. Using the current rules, the ENAR would attempt to send a RREP with TargAddr set to match TargAddr in the RREQ, and TargPrefixLen of 0.

TargPrefixLen of 0? Should that not be of 128 (a host route is a /128)? Well, I guess TargPrefixLen of 0 would make any advertisement into “a default route”, but I like the below (advertising 0/0) better.

> Even if the RREP contained TargAddr = 0.0.0.0 and TargPrefixLen of 0, RREQ_Gen could still match this with the RREQ it had sent and consider the route request fulfilled. Do you see a problem with this? We would need to update the wording and the current use of Prefix Length, since we currently interpret a prefix length of 0, and also the omission of prefix length value, to mean the full address length.

Hm, I think that something like that could work in terms of advertising a gateway into the network. The problem would be, how would you treat that on the router? Installing 0/0 into the FIB would cause your router to never send RREQs again ;) 

You would have to be keeping the 0/0 in your RIB, when getting a FIB miss then “look in <something> if this destination is expected to be inside the MANET” and unless that <something> tells you “no, it isn't”, could you use the 0/0 entry. 

But then again, the destination *could* still be reachable as a “locally attached network” to another router (say, your laptop) which I could reach within the MANET — but also, via Lotte’s laptop which is advertising 0/0.

So I guess my conclusion is: YES, but with some verbiage framing the addressing model (“The MANET has a prefix p::/$LENGTH. All destinations within that prefix are inside the MANET and a router MUST NOT use a 0/0 prefix for reaching them. All other prefixes are fair game”).

I don’t think that it’s necessary to document *all* addressing models that *could* work in the next revision, but this would be a fantastic thing to get started addressing.  What’s in the doc doesn’t really do much. This does something, subject to refinement as we go along?

And even better, I *think* that it can be generalized to the case (Lotte’s Laptop) mentioned above, although I have not thought that through completely.

Very glad that we’re seeing progress on gateways, finally, thank you for taking this up.

Best,

Thomas

>> On 07 Apr 2016, at 23:11, Thomas Heide Clausen <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> Assuming that is that a packet reception for forwarding is the only option you choose to allow. It's perfectly reasonable for an implementation to think "wouldn't it be sensible to learn about a gateway now for various reasons?".  Yes, there's the problem of which subnet to look for (0.0.0.0/0 <http://0.0.0.0/0> or something smaller). Yes, I can imagine you don't want to define this now - unless of course someone in the WG says they really want it. But I would say, don't close the door on it, even if not doing it now.
>>>