[Technical Errata Reported] RFC8175 (6472)

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[Technical Errata Reported] RFC8175 (6472)

rfc-editor
The following errata report has been submitted for RFC8175,
"Dynamic Link Exchange Protocol (DLEP)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6472

--------------------------------------
Type: Technical
Reported by: Rick Taylor <[hidden email]>

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.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8175 (draft-ietf-manet-dlep-29)
--------------------------------------
Title               : Dynamic Link Exchange Protocol (DLEP)
Publication Date    : June 2017
Author(s)           : S. Ratliff, S. Jury, D. Satterwhite, R. Taylor, B. Berry
Category            : PROPOSED STANDARD
Source              : Mobile Ad-hoc Networks
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
manet mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/manet
Reply | Threaded
Open this post in threaded view
|

Re: [Technical Errata Reported] RFC8175 (6472)

Rick Taylor
Hi All,

I shall be discussing this Errata in the Friday WG meeting.

Cheers,

Rick

> -----Original Message-----
> From: RFC Errata System [mailto:[hidden email]]
> Sent: 10 March 2021 16:03
> To: [hidden email]; [hidden email]; [hidden email];
> [hidden email]; [hidden email]; [hidden email];
> [hidden email]; [hidden email]
> Cc: Rick Taylor; [hidden email]; [hidden email]
> Subject: [Technical Errata Reported] RFC8175 (6472)
>
> The following errata report has been submitted for RFC8175,
> "Dynamic Link Exchange Protocol (DLEP)".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6472
>
> --------------------------------------
> Type: Technical
> Reported by: Rick Taylor <[hidden email]>
>
> 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.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC8175 (draft-ietf-manet-dlep-29)
> --------------------------------------
> Title               : Dynamic Link Exchange Protocol (DLEP)
> Publication Date    : June 2017
> Author(s)           : S. Ratliff, S. Jury, D. Satterwhite, R. Taylor, B. Berry
> Category            : PROPOSED STANDARD
> Source              : Mobile Ad-hoc Networks
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG
_______________________________________________
manet mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/manet
Reply | Threaded
Open this post in threaded view
|

Re: [Technical Errata Reported] RFC8175 (6472)

Alvaro Retana-2
[- 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.

_______________________________________________
manet mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/manet
Reply | Threaded
Open this post in threaded view
|

Re: [Technical Errata Reported] RFC8175 (6472)

Alvaro Retana-2
Ping!

On March 29, 2021 at 2:04:35 PM, Alvaro Retana ([hidden email]) 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.

_______________________________________________
manet mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/manet
Reply | Threaded
Open this post in threaded view
|

Re: [Technical Errata Reported] RFC8175 (6472)

Velt, R. (Ronald) in 't

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 <[hidden email]>
Sent: maandag 10 mei 2021 20:01
To: Rick Taylor <[hidden email]>; Velt, R. (Ronald) in 't <[hidden email]>; [hidden email]
Cc: [hidden email]
Subject: RE: [Technical Errata Reported] RFC8175 (6472)

 

Ping!

 

On March 29, 2021 at 2:04:35 PM, Alvaro Retana ([hidden email]) 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.

 

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.


_______________________________________________
manet mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/manet
Reply | Threaded
Open this post in threaded view
|

Re: [Technical Errata Reported] RFC8175 (6472)

Shawn Jury (sjury)

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" <[hidden email]>
Date: Monday, May 10, 2021 at 16:36
To: Alvaro Retana <[hidden email]>, Rick Taylor <[hidden email]>, "Shawn Jury (sjury)" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: RE: [Technical Errata Reported] RFC8175 (6472)

 

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 <[hidden email]>
Sent: maandag 10 mei 2021 20:01
To: Rick Taylor <[hidden email]>; Velt, R. (Ronald) in 't <[hidden email]>; [hidden email]
Cc: [hidden email]
Subject: RE: [Technical Errata Reported] RFC8175 (6472)

 

Ping!

 

On March 29, 2021 at 2:04:35 PM, Alvaro Retana ([hidden email]) 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.

 

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.


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

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Technical Errata Reported] RFC8175 (6472)

Rick Taylor

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

 

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" <[hidden email]>
Date: Monday, May 10, 2021 at 16:36
To: Alvaro Retana <[hidden email]>, Rick Taylor <[hidden email]>, "Shawn Jury (sjury)" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: RE: [Technical Errata Reported] RFC8175 (6472)

 

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 <[hidden email]>
Sent: maandag 10 mei 2021 20:01
To: Rick Taylor <[hidden email]>; Velt, R. (Ronald) in 't <[hidden email]>; [hidden email]
Cc: [hidden email]
Subject: RE: [Technical Errata Reported] RFC8175 (6472)

 

Ping!

 

On March 29, 2021 at 2:04:35 PM, Alvaro Retana ([hidden email]) 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.

 

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.


_______________________________________________
manet mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/manet
Reply | Threaded
Open this post in threaded view
|

Re: [Technical Errata Reported] RFC8175 (6472)

Velt, R. (Ronald) in 't
In reply to this post by Shawn Jury (sjury)

Hi Shawn,

 

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

 

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

 

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.

 

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.

 

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

 

OK

 

Ronald

 

-- 

Shawn Jury

Cisco Fed Systems Architect

Office:  919.392.6449

Cell:    919.225.4638

 

 

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

 

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 <[hidden email]>
Sent: maandag 10 mei 2021 20:01
To: Rick Taylor <[hidden email]>; Velt, R. (Ronald) in 't <[hidden email]>; [hidden email]
Cc: [hidden email]
Subject: RE: [Technical Errata Reported] RFC8175 (6472)

 

Ping!

 

On March 29, 2021 at 2:04:35 PM, Alvaro Retana ([hidden email]) 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.

 

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.


_______________________________________________
manet mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/manet
Reply | Threaded
Open this post in threaded view
|

FW: [Technical Errata Reported] RFC8175 (6472)

Velt, R. (Ronald) in 't
In reply to this post by Alvaro Retana-2

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 <[hidden email]>
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

 

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

 

Ping!

 

On March 29, 2021 at 2:04:35 PM, Alvaro Retana ([hidden email]) 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.

 

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.


_______________________________________________
manet mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/manet
Reply | Threaded
Open this post in threaded view
|

Re: [Technical Errata Reported] RFC8175 (6472)

Taylor, Rick-2

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

 

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 <[hidden email]>
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

 

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

 

Ping!

 

On March 29, 2021 at 2:04:35 PM, Alvaro Retana ([hidden email]) 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.

 

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.

 

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

_______________________________________________
manet mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/manet
Reply | Threaded
Open this post in threaded view
|

Re: [Technical Errata Reported] RFC8175 (6472)

Velt, R. (Ronald) in 't
In reply to this post by Rick Taylor

Hi Rick,

 

(inline)

 

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

 

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.

 

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” ?

 

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.

 

Agree.

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.

 

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).

 

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?

 

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

 

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" <[hidden email]>
Date: Monday, May 10, 2021 at 16:36
To: Alvaro Retana <[hidden email]>, Rick Taylor <[hidden email]>, "Shawn Jury (sjury)" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: RE: [Technical Errata Reported] RFC8175 (6472)

 

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 <[hidden email]>
Sent: maandag 10 mei 2021 20:01
To: Rick Taylor <[hidden email]>; Velt, R. (Ronald) in 't <[hidden email]>; [hidden email]
Cc: [hidden email]
Subject: RE: [Technical Errata Reported] RFC8175 (6472)

 

Ping!

 

On March 29, 2021 at 2:04:35 PM, Alvaro Retana ([hidden email]) 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.

 

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.


_______________________________________________
manet mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/manet
Reply | Threaded
Open this post in threaded view
|

Re: [Technical Errata Reported] RFC8175 (6472)

Taylor, Rick-2

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

 

Hi Rick,

 

(inline)

 

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

 

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.

 

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” ?

 

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.

 

Agree.

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.

 

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).

 

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?

 

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

 

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" <[hidden email]>
Date: Monday, May 10, 2021 at 16:36
To: Alvaro Retana <[hidden email]>, Rick Taylor <[hidden email]>, "Shawn Jury (sjury)" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: RE: [Technical Errata Reported] RFC8175 (6472)

 

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 <[hidden email]>
Sent: maandag 10 mei 2021 20:01
To: Rick Taylor <[hidden email]>; Velt, R. (Ronald) in 't <[hidden email]>; [hidden email]
Cc: [hidden email]
Subject: RE: [Technical Errata Reported] RFC8175 (6472)

 

Ping!

 

On March 29, 2021 at 2:04:35 PM, Alvaro Retana ([hidden email]) 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.

 

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.

 

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

_______________________________________________
manet mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/manet
Reply | Threaded
Open this post in threaded view
|

Re: [Technical Errata Reported] RFC8175 (6472)

Velt, R. (Ronald) in 't

Hi Rick,

 

(inline)

 

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

 

 

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)

 

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

 

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

 

Hi Rick,

 

(inline)

 

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

 

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.

 

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” ?

 

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.

 

Agree.

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.

 

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).

 

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?

 

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

 

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" <[hidden email]>
Date: Monday, May 10, 2021 at 16:36
To: Alvaro Retana <[hidden email]>, Rick Taylor <[hidden email]>, "Shawn Jury (sjury)" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: RE: [Technical Errata Reported] RFC8175 (6472)

 

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 <[hidden email]>
Sent: maandag 10 mei 2021 20:01
To: Rick Taylor <[hidden email]>; Velt, R. (Ronald) in 't <[hidden email]>; [hidden email]
Cc: [hidden email]
Subject: RE: [Technical Errata Reported] RFC8175 (6472)

 

Ping!

 

On March 29, 2021 at 2:04:35 PM, Alvaro Retana ([hidden email]) 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.

 

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.

 

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


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