Subject: RE: [Nsis-imp] Assigned numbers for version GIMPS -06

From: "Lang, Christopher" <[email-masked]>
Date: Mon, 11 Jul 2005 15:33:41 +0100

To be more specific: 

We have been using standard raw IP sockets with the IP_ROUTER_ALERT option to intercept packets. This method only works on Linux when the RAO value is 0 (see http://lxr.linux.no/source/net/ipv4/ip_options.c#L428). Also we only looked at IPv4 before we stuck to an RAO of 0. I don't know if raw IPv6 sockets work better or not.

It appears, from comments from Thomas, that it is possible to use any RAO value if the packets are intercepted using iptables and libipq (using a standard unpatched kernel) :-)

Chris Lang

> -----Original Message-----
> From: Lang, Christopher 
> Sent: 11 July 2005 10:46
> To: 'Xiaoming Fu'; Hancock, Robert
> Cc: [email-masked]
> Subject: RE: [Nsis-imp] Assigned numbers for version GIMPS -06
> 
> 
> Hi,
> 
> We have been using Linux as a platform (with a 2.6.7 kernel). 
> Using non-zero RAO values we intially found that GIMPS 
> messages were not being picked up by intermediate nodes. 
> Inspection of the Kernel source revealed that the Linux 
> kernel ignores all RAO values except 0. 
> 
> There also does not appear to be support for picking out any 
> RAO packets in Windows.
> 
> Which platform have you been using?
> 
> Chris Lang
> 
> > -----Original Message-----
> > From: Xiaoming Fu [mailto:[email-masked]]
> > Sent: 07 July 2005 17:47
> > To: Hancock, Robert
> > Cc: [email-masked]
> > Subject: Re: [Nsis-imp] Assigned numbers for version GIMPS -06
> > 
> > 
> > Hancock, Robert wrote:
> > >>My point was, to rely on NLI TLV to determine the size of PI (by 
> > >>minus other fields) may be simple but not efficient for 
> processing.
> > > 
> > > from C.4.3 (the NLI format):
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |   PI-Length   |    IP-TTL     |IP-Ver |        
> Reserved       |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    PI-Length = the byte length of the Peer-Identity field
> > >                (note that the Peer-Identity field itself is padded
> > >                to a whole number of words)
> > > 
> > > i'm not sure what encoding the PI as a separate object
> > would buy you
> > > here.
> > Sorry, I have missed this field.
> > 
> > > but see for example the end of the second paragraph of 
> 3.1, "If the
> > > routing state does not exist, it may be possible for GIMPS 
> > to send a
> > > message anyway, with the same encapsulation as used for a Query
> > > message."
> > 
> > Well, a GIMPS engine will always do whatever it is supposed to, as
> > long as the task is part of the 'spec' and the implementation.
> > 
> > >>>- the RAO value of 0 is not realistic and in principle would
> > >>>  be NSLPID dependent. but exactly what the values should be
> > >>>  is a question for John's draft - or something like it ;-)
> > >>
> > >>That's what I also guessed but there was a question of 
> being "0". I
> > >>like John's statement "An NSLPID must be associated with a 
> > unique RAO
> > >>value." Assuming a preliminary one for basic testing would
> > be needed,
> > >>possibly using e.g., "diagnostics/ping/traceroute" function.
> > > 
> > > 
> > > yep - you'll find the same statement about NSLPIDs in the
> > GIMPS draft,
> > > btw. but the point is, we can't allocate a 'real' ourselves
> > (without
> > > going to IANA), so we just picked an easy one. Some IP
> > stacks seem to
> > > have a problem with values other than 0, in our experience.
> > > 
> > Good to know of this. Any example platform?
> > Xiaoming
> > 
> > _______________________________________________
> > NSIS-imp mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis-imp
> > 
> 
> _______________________________________________
> NSIS-imp mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis-imp
> 

_______________________________________________
NSIS-imp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis-imp

---

From: Thomas Herzog <[email-masked]>
Date: Mon, 11 Jul 2005 19:03:18 +0200

To be a little bit more specific:

For IPv6, you theoretically do not even need to use a RAW socket, to 
read RAO options, of course, you need them to intercept the packets 
which are not addressed to us but to the flow sink/source... "man ipv6" 
tells us:

>      IPV6_RTHDR, IPV6_AUTHHDR, IPV6_DSTOPS, IPV6_HOPOPTS, IPV6_FLOWINFO, IPV6_HOPLIMIT
>               Set delivery of control messages for incoming datagrams containing extension headers from the received packet.   IPV6_RTHDR  delivers  the
>               routing  header, IPV6_AUTHHDR delivers the authentication header, IPV6_DSTOPTS delivers the destination options, IPV6_HOPOPTS delivers the
>               hop options, IPV6_FLOWINFO delivers an integer containing the flow id, IPV6_HOPLIMIT delivers an integer containing the hop count  of  the
>               packet.   The  control  messages have the same type as the socket option. All these header options can also be set for outgoing packets by
>               putting the appropriate control message into the control buffer of sendmsg(2).  Only allowed for SOCK_DGRAM or SOCK_RAW sockets.  Argument
>               is a pointer to a boolean value.
> 

A recvmsg on the socket should deliver the packet in a msghdr structure 
along with all the Hop-by-Hop options in the ancillary data.

On a different approach, via iptables/libipq, also all RAO values can be 
read easily in both IPv4 and IPv6.

Cheers,
Thomas

---

From: Xiaoming Fu <[email-masked]>
Date: Tue, 12 Jul 2005 12:31:48 +0200

Good, this reminds me of the programming error we had before. The 
result was found to be that "Set IP_ROUTER_ALERT ON" in our Linux 
2.6 must be used - which represents the case where RAO value is set 
as 0. (This conforms to RFC2113 that only value 0 is allocated for 
current use.) The appearence of a RAO (having value 0) + port number 
identifies a message being a discovery.

Below is our code segment (for IPv4 and v6 in scoutd in our CASP 
implementation):

/*****************************************************************
  Set IP_ROUTER_ALERT option to "on"  in given socket
  returns 0 on success and -1 on failure
******************************************************************/
int r_alert_recv_on(int socket)
{
   int on = TRUE;

   /* insert ipv4/v6 differentiation here and set correctly */

   if (ip_version_get() == 4)
     {

       if ((setsockopt(socket,SOL_IP,IP_ROUTER_ALERT,
		      (char *) &on,sizeof(on))) < 0)
	return -1;
     }
   else
     {
       if ((setsockopt(socket,SOL_IPV6,IP_ROUTER_ALERT,
		      (char *) &on,sizeof(on))) < 0)
	{
	  /*printf("Error: %i\n\n", errno);*/
	  return -1;
	}
     }

   return 0;
}

Xiaoming