Subject: Re: [manet] [Technical Errata Reported] RFC8175 (6472)

From: Alvaro Retana <[email-masked]>
Date: Mon, 10 May 2021 14:00:43 -0400

Ping!

On March 29, 2021 at 2:04:35 PM, Alvaro Retana ([email-masked])
wrote:

[- Rick’s additional address, RFC Editor, other ADs.]

On March 10, 2021 at 11:05:03 AM, Rick Taylor wrote:

Hi!

I'm processing this report...but I have a question.  What do current
implementations do?  See move below.

...
> > Section: 12.4, para 2
> >
> > Original Text
> > -------------
> > A Peer Offer Signal MUST be encoded within a UDP packet. The IP source
> > and destination fields in the packet MUST be set by swapping the values
> > received in the Peer Discovery Signal. The Peer Offer Signal completes
the
> > discovery process; see Section 7.1.
> >
> > Corrected Text
> > --------------
> > A Peer Offer Signal MUST be encoded within a UDP packet. If the Modem
is
> > not including IPv4 and IPv6 Connection Point Data Items in the Peer
Offer
> > Signal, then the IP source field in the packet MUST be set to the
unicast
> > address the router must use when connecting the DLEP TCP session,
> > otherwise any valid local address MUST be used. The IP destination
field
> > in the packet MUST be set to the IP source field value received in the
> > Peer Discovery Signal. The Peer Offer Signal completes the discovery
> > process; see Section 7.1.
> >
> > Notes
> > -----
> > The original text will not result in a valid unicast IP packet.

The new text is this:

   If the Modem is not including IPv4 and IPv6 Connection Point Data Items
in
   the Peer Offer Signal, then the IP source field in the packet MUST be
set
   to the unicast address the router must use when connecting the DLEP TCP
   session, otherwise any valid local address MUST be used.

I am having an issue with the double MUST.  Regardless of whether a
Connection Point Data Item is present, why wouldn't it be required (or at
least recommended) to always use the TCP-related IP address?

Proposal (to replace the new text)>
   The source IP address SHOULD be the address the peer should use when
   connecting the DLEP TCP session.  If a Connection Point Data Item is
   included, any valid local address MAY be used instead.

??

Thanks!

Alvaro.

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Mon, 10 May 2021 20:35:45 +0000

Hi,

I forwarded the message below to Henning Rogge in order to get one more datapoint on the question what current implementations do. (Maybe we should ask David Wiggins as well).

With respect to the text correction, I can see the issue with the double MUST. However, in the proposed alternative, there is no MUST at all, just a SHOULD (and a lower case ‘should’). Somehow, that does not seem entirely right to me. So far, I have not been able to come up with anything better, though. I’ll think about it some more. BTW, what about the phrasing of “If the Modem is not including IPv4 and IPv6 Connection Point Data Items …”; shouldn’t that read: “If the Modem is including neither an IPv4 Connection Point Data Item nor an IPv6 Connection Point Data Item …”? What if the Modem is including just a IPv6 Connection Point Data Item, but the Peer Discovery Signal was sent over IPv4 (or vice versa)? Should we elaborate here to stave off future errata?

Regards,
Ronald

From: Alvaro Retana <[email-masked]>
Sent: maandag 10 mei 2021 20:01
To: Rick Taylor <[email-masked]>; Velt, R. (Ronald) in 't <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Technical Errata Reported] RFC8175 (6472)

Ping!

On March 29, 2021 at 2:04:35 PM, Alvaro Retana ([email-masked]<mailto:[email-masked]>) wrote:
[- Rick’s additional address, RFC Editor, other ADs.]

Hi!

I'm processing this report...but I have a question.  What do current implementations do?  See move below.

...
> > received in the Peer Discovery Signal. The Peer Offer Signal completes the
> > A Peer Offer Signal MUST be encoded within a UDP packet. If the Modem is
> > not including IPv4 and IPv6 Connection Point Data Items in the Peer Offer
> > Signal, then the IP source field in the packet MUST be set to the unicast
> > otherwise any valid local address MUST be used. The IP destination field

The new text is this:

   If the Modem is not including IPv4 and IPv6 Connection Point Data Items in
   the Peer Offer Signal, then the IP source field in the packet MUST be set
   to the unicast address the router must use when connecting the DLEP TCP
   session, otherwise any valid local address MUST be used.

I am having an issue with the double MUST.  Regardless of whether a Connection Point Data Item is present, why wouldn't it be required (or at least recommended) to always use the TCP-related IP address?

??

Thanks!

Alvaro.
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: "Shawn Jury (sjury)" <[email-masked]>
Date: Mon, 10 May 2021 20:47:06 +0000

Hey Ronald,

    Some of what you are talking about is in Section 7.1 p4.  Check that out to see if it answers your concern.

    I have asked my developers to check how we handle this situation in our implementation.

-- 

Shawn Jury

Cisco Fed Systems Architect

Office:  919.392.6449

Cell:    919.225.4638

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Monday, May 10, 2021 at 16:36
To: Alvaro Retana <[email-masked]>, Rick Taylor <[email-masked]>, "Shawn Jury (sjury)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [Technical Errata Reported] RFC8175 (6472)

Hi,

Regards,

Ronald

Ping!

On March 29, 2021 at 2:04:35 PM, Alvaro Retana ([email-masked]) wrote:

Hi! 

... 

The new text is this: 

?? 

Thanks! 

Alvaro.

---

From: Rick Taylor <[email-masked]>
Date: Wed, 12 May 2021 08:37:46 +0000

Hi All,

Just to clarify the issue.  RFC 8175, Section 7.1 p4 says that the Peer Offer is unicast back to the multicast address, which is obviously nonsense.

The other issue discovered, is that no mention is made of the UDP port to be used for the response.

My suggestion is that the correction is:

1.       The Peer Offer MUST be unicast back to the source IP address *and port* of the received multicast Peer Discovery signal.

2.       The Source Address/Port of the Peer Offer signal MUST be the Address/Port to be used for the new TCP session, *unless* IPv4 and/or IPv6 Connection Point data items are included in which case the Address/Port combination are irrelevant.

This behaviour is consistent with the LL-DLEP (MIT) code, and our (Airbus) code.

Now we just need to turn that into ‘standards language’…   Is there MUST/UNLESS language in 8174 we can use?

Cheers,

Rick

From: Shawn Jury (sjury) [mailto:[email-masked]]
Sent: 10 May 2021 21:47
To: Velt, R. (Ronald) in 't; Alvaro Retana; Rick Taylor
Cc: [email-masked]; Shawn Jury (sjury)
Subject: Re: [Technical Errata Reported] RFC8175 (6472)

Hey Ronald,

Hi,

Regards,
Ronald

Ping!

Hi!

...

The new text is this:

??

Thanks!

Alvaro.

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Wed, 12 May 2021 13:27:52 +0000

Hi Shawn,

Thanks and good to hear from you. Please see below.

From: Shawn Jury (sjury) <[email-masked]>
Sent: maandag 10 mei 2021 22:47
To: Velt, R. (Ronald) in 't <[email-masked]>; Alvaro Retana <[email-masked]>; Rick Taylor <[email-masked]>
Cc: [email-masked]; Shawn Jury (sjury) <[email-masked]>
Subject: Re: [Technical Errata Reported] RFC8175 (6472)

Hey Ronald,

To a degree it does, but not completely. I do admit that I had overlooked that paragraph. I’ll discuss more in reply to Rick Taylor’s mail of today.

OK

Ronald

From: "Velt, R. (Ronald) in 't" <[email-masked]<mailto:[email-masked]>>
Date: Monday, May 10, 2021 at 16:36
To: Alvaro Retana <[email-masked]<mailto:[email-masked]>>, Rick Taylor <[email-masked]<mailto:[email-masked]>>, "Shawn Jury (sjury)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Technical Errata Reported] RFC8175 (6472)

Hi,

Regards,
Ronald

From: Alvaro Retana <[email-masked]<mailto:[email-masked]>>
Sent: maandag 10 mei 2021 20:01
To: Rick Taylor <[email-masked]<mailto:[email-masked]>>; Velt, R. (Ronald) in 't <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Technical Errata Reported] RFC8175 (6472)

Ping!

Hi!

...

The new text is this:

??

Thanks!

Alvaro.

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Wed, 12 May 2021 13:31:35 +0000

Henning Rogge says:

Hi Ronald,

I just checked my OLSR-DLEP implementation...

I first look for an IPv6 connection point, then (if I get none) for an IPv4 connection point... and only after both of them don't exist I just take the remote-IP (source IP) of the UDP packet arriving at the router to establish a DLEP session.

So my implementation would be okay if the IP-source of the UDP Source-IP would be something "other" than the TCP-Connection point as long as a "connection point" is delivered...

if we demand that the source-IP is the right one, we don't need the connection points anymore, right?

Henning

________________________________
Von: Velt, R. (Ronald) in 't <[email-masked]<mailto:[email-masked]>>
Gesendet: Montag, 10. Mai 2021 20:21
An: Rogge, Henning
Betreff: FW: [Technical Errata Reported] RFC8175 (6472)

Hi Henning,

Please see Alvaro's question below. What does _your_ implementation (old/new) do? Any comment on Alvaro's proposed text correction versus the text proposed by Rick?

Thanks,
Ronald

Ping!

On March 29, 2021 at 2:04:35 PM, Alvaro Retana ([email-masked]<mailto:[email-masked]>) wrote:
[- Rick's additional address, RFC Editor, other ADs.]

Hi!

...

The new text is this:

??

Thanks!

Alvaro.

---

From: "Taylor, Rick" <[email-masked]>
Date: Wed, 12 May 2021 13:41:14 +0000

Hi Henning,

What we have tried to do is provide flexibility and added complexity.  We provide the ability to handle the following use-cases:

*         Listen on multicast IPv4 and support sessions on IPv6

*         Listen for multicast on one port, but support TCP on a different port

*         Listen for multicast on an interface, but only support specific addresses for the TCP session

*         Just use any address on an interface for discovery and session.

Because of this getting the word-smithing is tricky.

Cheers,

Rick

From: manet [mailto:[email-masked]] On Behalf Of Velt, R. (Ronald) in 't
Sent: Wednesday, May 12, 2021 2:32 PM
To: Alvaro Retana <[email-masked]>; Rick Taylor <[email-masked]>
Cc: [email-masked]
Subject: [manet] FW: [Technical Errata Reported] RFC8175 (6472)

Henning Rogge says:

Hi Ronald,

Henning

Hi Henning,

Thanks,
Ronald

Ping!

Hi!

...

The new text is this:

??

Thanks!

Alvaro.

THIS DOCUMENT IS NOT SUBJECT TO EXPORT CONTROL.

This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Airbus Defence and Space Limited disclaims any and all liability if this email transmission was virus corrupted, altered or falsified.
-o-
Emails to Airbus Defence and Space Limited may be processed, recorded and monitored outside the UK.
-o-
Airbus Defence and Space Limited, Registered in England and Wales No. 2449259
Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Wed, 12 May 2021 15:04:16 +0000

Hi Rick,

(inline)

From: manet <[email-masked]> On Behalf Of Rick Taylor
Sent: woensdag 12 mei 2021 10:38
To: Shawn Jury (sjury) <[email-masked]>; Velt, R. (Ronald) in 't <[email-masked]>; Alvaro Retana <[email-masked]>
Cc: [email-masked]
Subject: Re: [manet] [Technical Errata Reported] RFC8175 (6472)

Hi All,

I don’t think Section 7.1 p 4 says that. Did you mean: "RFC 8175, Section 12.4 para 2 says that the Peer Offer is unicast back to the router with a multicast source address, which is obviously nonsense” ?

Agree.

I think this should read:

The Source Address/Port of the Peer Offer signal MUST be the Address/Port to be used for the new TCP session, *unless* IPv4 and/or IPv6 Connection Point data items are included. In the latter case, any valid local address and an arbitrary port number can be used.

(A namespace purist might object that in case the Peer Offer does not contain Connection Point data items, a UDP port number (in casu, the source port number of the Peer Offer) is re-interpreted / repurposed as a TCP port number).

Staying closer to corrected text you initially proposed:

   If the Modem is including neither IPv4 nor IPv6 Connection Point Data Items in the Peer Offer Signal, then the IP source field and the UDP source port in the packet MUST be set
   to the unicast address and the TCP destination port for the router to use when connecting the DLEP TCP session, otherwise any valid local address and an arbitrary port number can be used.

(With the same namespace caveat as above).

What do you think?

Ronald

Cheers,

Rick

From: Shawn Jury (sjury) [mailto:[email-masked]]
Sent: 10 May 2021 21:47
To: Velt, R. (Ronald) in 't; Alvaro Retana; Rick Taylor
Cc: [email-masked]<mailto:[email-masked]>; Shawn Jury (sjury)
Subject: Re: [Technical Errata Reported] RFC8175 (6472)

Hey Ronald,

Hi,

Regards,
Ronald

Ping!

Hi!

...

The new text is this:

??

Thanks!

Alvaro.

---

From: "Taylor, Rick" <[email-masked]>
Date: Wed, 12 May 2021 15:13:16 +0000

Hi Ronald,

I think that’s pretty close to perfect.  Logically correct, but I do worry about the ‘neither … nor’ language.  That construct can confuse native language speakers so it cannot be easier for non-native, but I’m not one to judge.

Perhaps a US-English speaker (where I believe neither+nor is less common) would care to judge?

Cheers,

Rick

From: manet [mailto:[email-masked]] On Behalf Of Velt, R. (Ronald) in 't
Sent: Wednesday, May 12, 2021 4:04 PM
To: Rick Taylor <[email-masked]>; Shawn Jury (sjury) <[email-masked]>; Alvaro Retana <[email-masked]>
Cc: [email-masked]
Subject: Re: [manet] [Technical Errata Reported] RFC8175 (6472)

Hi Rick,

(inline)

From: manet <[email-masked]<mailto:[email-masked]>> On Behalf Of Rick Taylor
Sent: woensdag 12 mei 2021 10:38
To: Shawn Jury (sjury) <[email-masked]<mailto:[email-masked]>>; Velt, R. (Ronald) in 't <[email-masked]<mailto:[email-masked]>>; Alvaro Retana <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [manet] [Technical Errata Reported] RFC8175 (6472)

Hi All,

Agree.

What do you think?

Ronald

Cheers,

Rick

Hey Ronald,

Hi,

Regards,
Ronald

Ping!

Hi!

...

The new text is this:

??

Thanks!

Alvaro.

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Fri, 14 May 2021 16:09:33 +0000

Hi Rick,

(inline)

From: Taylor, Rick <[email-masked]>
Sent: woensdag 12 mei 2021 17:13
To: Velt, R. (Ronald) in 't <[email-masked]>; Rick Taylor <[email-masked]>; Shawn Jury (sjury) <[email-masked]>; Alvaro Retana <[email-masked]>
Cc: [email-masked]
Subject: RE: [Technical Errata Reported] RFC8175 (6472)

Hi Ronald,

Perhaps a US-English speaker (where I believe neither+nor is less common)

Really? So Bill Bryson had been living in the UK for too long already when he wrote https://en.wikipedia.org/wiki/Neither_Here_nor_There:_Travels_in_Europe ?

would care to judge?

That does not seem to be the case …

Cheers,
Ronald
(non-native English speaker)

Cheers,

Rick

To: Rick Taylor <[email-masked]<mailto:[email-masked]>>; Shawn Jury (sjury) <[email-masked]<mailto:[email-masked]>>; Alvaro Retana <[email-masked]<mailto:[email-masked]>>

Hi Rick,

(inline)

Hi All,

Agree.

What do you think?

Ronald

Cheers,

Rick

Hey Ronald,

Hi,

Regards,
Ronald

Ping!

Hi!

...

The new text is this:

??

Thanks!

Alvaro.