Subject: [manet] Dual stack operations (was RE: draft-ietf-manet-olsrv2-management-snapshot-02)

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 22 Aug 2014 09:14:36 +0000

(Changed subject line. As far as management draft is concerned this is one of those possible futures.)

I need to read your draft. I don't understand from your comment the relevance of the hop limit greater than one or how it addresses the issue.

I think we are both agreed that a second level of multiplexing is implicit. Should it be explicit?

Also suppose we have IPv4 and IPv6 versions of NHDP and OLSRv2. We can demultiplex 4 and 16 byte addressed HELLO and TC messages appropriately. What should we do with a, say, 2 byte address? Should address expansion to one or the other be allowed? (the quote you give - thanks - disallows this).

And, as I didn't fully say, NHDP may use the IP source address to avoid having to include a sending interface address (otherwise using LOCAL_IF). That needs covering if the HELLO address length and IP address length don't match. That can be done by not doing that. What I didn't say at all is that OLSRv2 uses the sending address to know whether to forward the message. That can't be handled by not doing that, and needs a solution.

-- 
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

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: manet [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 22 August 2014 09:05
To: [email-masked]
Subject: Re: [manet] draft-ietf-manet-olsrv2-management-snapshot-02

On 08/22/2014 09:46 AM, Christopher Dearlove wrote:
> No, not quite the same. 5444 explicitly discusses separate protocols.
> It doesn't explicitly discuss address lengths. The 5444 model assumes 
> that all HELLO messages are sent to a single entity, regardless of 
> address type. (It doesn't say regardless of address type, it just 
> doesn't mention it.) That would be NHDP of course. But the NHDP 
> description is of a protocol that has a certain type of address. I 
> don't recall if it explicitly says drop HELLO messages with wrong 
> address length or not.

http://tools.ietf.org/html/rfc6130#section-12.1

A received HELLO message is invalid for processing by this router if any of the following conditions are true:

o  The address length as specified in the Message Header is not equal
   to the length of the addresses used by this router.

> There's nothing actually specified anywhere which describes a process 
> something like 5444 gets HELLO, sends to NHDP. NHDP looks at address 
> length and sends to NHDP/IPv4 or NHDP/IPv6 for address lengths 4 or
> 16 (and drops HELLO messages with other lengths?). Here NHPD/IPv4 and
> NHDP/IPv6 are separate instantiations of 6130. (And ditto for
> OLSRv2.) Of course that's a reasonably obvious approach, just not 
> explicitly specified anywhere,because 5444 can say it's up to the 
> protocol, and the protocol can say it's really a multiplexing thing.

You could argue that if you want to do a dualstack thing, you just need a second level of multiplexer.

> And the comment that messages have no constraints on the IP address 
> type of the surrounding packet is true for 5444. It's not true for 
> NHDP, which uses the IP datagram source address. That's actually an 
> issue that a dual stack approach needs to cover.

My draft already covers this, it only allows messages with a hop-limit larger than one to be put into a UDP/RFC-5444 packet with a different address length.

Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

********************************************************************
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: Henning Rogge <[email-masked]>
Date: Fri, 22 Aug 2014 11:29:18 +0200

> I need to read your draft. I don't understand from your comment the relevance of the hop limit greater than one or how it addresses the issue.

I think yes, because everything with hoplimit>1 will be forwarded by
other nodes, which changes the src-ip address.

> I think we are both agreed that a second level of multiplexing is implicit. Should it be explicit?

Phh... good question. I don't know. Some implementation might just
combine both multiplexing decisions, some might just have a protocol
that understands two different kind of address types (or more).

> Also suppose we have IPv4 and IPv6 versions of NHDP and OLSRv2. We can demultiplex 4 and 16 byte addressed HELLO and TC messages appropriately. What should we do with a, say, 2 byte address? Should…

I do the same a "single address family" implementation is doing. When
I get a message with an address length I don't support (in the case of
my dualstack implementation, 4 and 16) I drop the address.

> And, as I didn't fully say, NHDP may use the IP source address to avoid having to include a sending interface address (otherwise using LOCAL_IF). That needs covering if the HELLO address length and…

The forwarding can be done based on the MPR set fitting the the IP
address of the incoming packet, the duplicate detection will be then
done by using the Duplicate Set with the address length of the
message.

Example:
***********

you get a IPv4 OLSRv2 message inside an IPv6 UDP packet (with an
RFC5444 packet header inside).

You first check the IPv6 flooding MPR set if you should forward the
message at all (based on the IPv6 NHDP Hello messages). If yes, you
check in the IPv4 duplicate set if you already have forwarded the
message, based on the message header fields of the RFC5444 message
with address length 4.

(I have to remember to put this explanation into the next revision of
the dualstack draft)

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 22 Aug 2014 11:32:46 +0000

Aha, when you refer to hop limit, you mean IP hop limit. I think that's redundant, we already say that.

Use of the IPv6 process's information to decide whether to flood an IPv4 message (or vice versa) strikes me as dodgy at best. It assumes that everything is the same in the IPv4 and IPv6 worlds: same set of routers, same links and their status etc. I think this needs more consideration.

(Terminologically, we don't have an MPR Set - now flags in the Neighbor Set - or Duplicate Set - divided in three. Doesn't matter here, matters when writing drafts.)

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 22 August 2014 10:29
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [manet] Dual stack operations (was RE: draft-ietf-manet-olsrv2-management-snapshot-02)

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

> I need to read your draft. I don't understand from your comment the relevance of the hop limit greater than one or how it addresses the issue.

I think yes, because everything with hoplimit>1 will be forwarded by other nodes, which changes the src-ip address.

> I think we are both agreed that a second level of multiplexing is implicit. Should it be explicit?

Phh... good question. I don't know. Some implementation might just combine both multiplexing decisions, some might just have a protocol that understands two different kind of address types (or more).

> Also suppose we have IPv4 and IPv6 versions of NHDP and OLSRv2. We can demultiplex 4 and 16 byte addressed HELLO and TC messages appropriately. What should we do with a, say, 2 byte address? Should…

I do the same a "single address family" implementation is doing. When I get a message with an address length I don't support (in the case of my dualstack implementation, 4 and 16) I drop the address.

> And, as I didn't fully say, NHDP may use the IP source address to avoid having to include a sending interface address (otherwise using LOCAL_IF). That needs covering if the HELLO address length and…

The forwarding can be done based on the MPR set fitting the the IP address of the incoming packet, the duplicate detection will be then done by using the Duplicate Set with the address length of the message.

Example:
***********

You first check the IPv6 flooding MPR set if you should forward the message at all (based on the IPv6 NHDP Hello messages). If yes, you check in the IPv4 duplicate set if you already have forwarded the message, based on the message header fields of the RFC5444 message with address length 4.

(I have to remember to put this explanation into the next revision of the dualstack draft)

Henning Rogge

_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet

---

From: Henning Rogge <[email-masked]>
Date: Fri, 22 Aug 2014 14:17:37 +0200

> Aha, when you refer to hop limit, you mean IP hop limit. I think that's redundant, we already say that.

No, I am talking about the RFC5444 message header field "Hop Limit".

> Use of the IPv6 process's information to decide whether to flood an IPv4 message (or vice versa) strikes me as dodgy at best. It assumes that everything is the same in the IPv4 and IPv6 worlds: sam…

You only use the IPv6 MPRs for an IPv4 (RFC5444) message if you don't
have neighbors that are "IPv4 only". That's in the rules in chapter
7.5 of my draft.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 22 Aug 2014 14:17:40 +0000

OK, with regard to hop limit, I'm back with it.

> My draft already covers this, it only allows messages with a hop-limit larger than one to be put into a UDP/RFC-5444 packet with a different address length.

Or in other words, you can't put HELLO messages in an IP datagram (that's the level that matters) for another size limit. But you can put (every real) TC messages there.
That's unnecessarily restricting, at least in principle, as HELLO messages don't have to use the IP source address. It would be possible to say in that case there's an error. Of course that would extend 6130, which would be an issue in something experimental.

I need to read your draft. But I'd want to see a proof that messages always get where they need to go. What if you have 2-hop neighbours that are IPv4 only? Will the IPv6 MPRs cover them? And I'm still doubtful about different IPv4/v6 link states and interaction with MPR selection. What if you use link metrics in flooding MPR selection (an allowed option)?

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 22 August 2014 13:18
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [manet] Dual stack operations (was RE: draft-ietf-manet-olsrv2-management-snapshot-02)

> Use of the IPv6 process's information to decide whether to flood an IPv4 message (or vice versa) strikes me as dodgy at best. It assumes that everything is the same in the IPv4 and IPv6 worlds: sam…

You only use the IPv6 MPRs for an IPv4 (RFC5444) message if you don't have neighbors that are "IPv4 only". That's in the rules in chapter
7.5 of my draft.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Sat, 23 Aug 2014 12:26:35 +0200

On Fri, Aug 22, 2014 at 4:17 PM, Dearlove, Christopher (UK)
<[email-masked]> wrote:
> Or in other words, you can't put HELLO messages in an IP datagram (that's the level that matters) for another size limit.
Exactly.

> But you can put (every real) TC messages there.
Yes.

I restrict the "dualstack" optimization to multihop messages just to
be sure I don't grab a message that needs the source-IP address.

> That's unnecessarily restricting, at least in principle, as HELLO messages don't have to use the IP source address. It would be possible to say in that case there's an error. Of course that would e…

And it would make the whole thing a LOT more complicated.

> I need to read your draft. But I'd want to see a proof that messages always get where they need to go. What if you have 2-hop neighbours that are IPv4 only? Will the IPv6 MPRs cover them? And I'm s…

Thats a good point, i have to look into the MPR calculation again,
most likely there is additional work to do.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Sun, 24 Aug 2014 11:06:31 +0200

> most likely there is additional work to do.

Okay,

I had some time to think about the MPR situation and I think it will
work without adding a third MPR set... but we (somehow) have to use
the IPv4 MPR set for IPv4 messages, even if they come inside an IPv6
UDP packet (plus RFC5444 header of course).

So the trick is to determine the "other" IP address of your neighbors
interfaces... so that you can take (as an example) the IPv6 source
address, transform it into an IPv4 source address of the same
interface of the neighbor and then use the IPv4 MPR set and duplicate
set.

I think this should already be possible with the existing data
structure, because it stores the "ipv4 originator" in the IPv6 Link
Set Tuple, which means we can search for the corresponding IPv4 Link
Set Tuple on the same interface.

Thank you for finding this issue, I will work on formulating the necessary text.

Henning Rogge