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

["Lang, Christopher" <[e-mail]>]

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: [e-mail]
> 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:[e-mail]]
> > Sent: 07 July 2005 17:47
> > To: Hancock, Robert
> > Cc: [e-mail]
> > 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/nsis-imp
> > 
> 
> _______________________________________________
> NSIS-imp mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nsis-imp
> 

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