Re: RFC3927 ARP patch status?

Re: RFC3927 ARP patch status?

[David Daney]

Anand Kumria wrote:
> Hi David,
> 
> Do you know the status of your RFC3927 ARP patch? Is it likely to make
> it into a mainline kernel?
> 

That would be up to the kernel network maintainers.

There were some discussions about whether it made sense for the kernel 
to support the behavior required by the RFC.  Other comments debated the 
wisdom of using a tightly targeted patch specific to the RFC, or whether 
a more general but intrusive solution would be better.

The patch is there.  I signed-off-by on it.

If you need RFC3927 compliance, you are free to apply the patch.  If the 
  network maintainers are so inclined, they can do the necessary things 
to get it into the mainline.

David Daney

Re: RFC3927 ARP patch status?

[Anand Kumria]

On Fri, Jun 02, 2006 at 09:36:54AM -0700, David Daney wrote:
> Anand Kumria wrote:
> >Hi David,
> >
> >Do you know the status of your RFC3927 ARP patch? Is it likely to make
> >it into a mainline kernel?
> >
> 
> That would be up to the kernel network maintainers.
> 
> There were some discussions about whether it made sense for the kernel 
> to support the behavior required by the RFC.  Other comments debated the 

Hmm, well the behaviour at the moment is certainly suboptimal. Any
compliant RFC3927 implementation has to generate an additional broadcast
ARP -- the kernel will send a directed response, which isn't enough.

> The patch is there.  I signed-off-by on it.
> 
> If you need RFC3927 compliance, you are free to apply the patch.  If the 
>  network maintainers are so inclined, they can do the necessary things 
> to get it into the mainline.

Okay, thanks.

Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"

Re: RFC3927 ARP patch status?

[Herbert Xu]

David Daney <ddaney@avtrex.com> wrote:
> 
> There were some discussions about whether it made sense for the kernel 
> to support the behavior required by the RFC.  Other comments debated the 
> wisdom of using a tightly targeted patch specific to the RFC, or whether 
> a more general but intrusive solution would be better.

I think we've made it quite clear what needs to be done for it to be
accepted.  All that remains is for someone to implement it.  If anyone
really cares about this, then please write the code instead of talking
about it.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: RFC3927 ARP patch status?

[Anand Kumria]

Herbert,

On Sat, Jun 03, 2006 at 09:12:06AM +1000, Herbert Xu wrote:
> David Daney <ddaney@avtrex.com> wrote:
> > 
> > There were some discussions about whether it made sense for the kernel 
> > to support the behavior required by the RFC.  Other comments debated the 
> > wisdom of using a tightly targeted patch specific to the RFC, or whether 
> > a more general but intrusive solution would be better.
> 
> I think we've made it quite clear what needs to be done for it to be
> accepted.  All that remains is for someone to implement it.  If anyone
> really cares about this, then please write the code instead of talking
> about it.

Okay, to confirm: you want a patch which looks at the scope value and if 
the scope is link-local then we broadcast rather than do a directed ARP?

One I have where IPv6 encodes what address mask is link-local,
I'd like to follow the same style as. Should the kernel also set the
scope on IPv4 addresses like it does for IPv6 ones?

Thanks,
Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"

Re: RFC3927 ARP patch status?

[David Miller]

RFC3927 seem to be an intellectual property mine field, I really don't
see how we can include this in the Linux kernel.

Go to "http://www.ietf.org/ipr", click on "Search the IPR
disclosures", then enter "3927" in the "Enter RFC number" field and
click SEARCH.

Re: RFC3927 ARP patch status?

[David Daney]

David Miller wrote:
> RFC3927 seem to be an intellectual property mine field, I really don't
> see how we can include this in the Linux kernel.
> 
> Go to "http://www.ietf.org/ipr", click on "Search the IPR
> disclosures", then enter "3927" in the "Enter RFC number" field and
> click SEARCH.

RFC3927 may be a mine field, but the only thing that has to be changed 
in the kernel to support it is to somehow configure the arp driver to 
broadcast unconditionally on certain interfaces.  The majority of the 
rfc3927 protocol is done by userspace applications, so should *not* 
really effect the kernel.

David Daney.

Re: RFC3927 ARP patch status?

[David Miller]

From: David Daney <ddaney@avtrex.com>
Date: Fri, 02 Jun 2006 17:55:17 -0700

> RFC3927 may be a mine field, but the only thing that has to be changed 
> in the kernel to support it is to somehow configure the arp driver to 
> broadcast unconditionally on certain interfaces.

Ok, I'd have to see the final patch after Herbert's suggestions
are taken into account.

Re: RFC3927 ARP patch status?

[David Daney]

Anand Kumria wrote:
> Herbert,
> 
> On Sat, Jun 03, 2006 at 09:12:06AM +1000, Herbert Xu wrote:
> 
>>David Daney <ddaney@avtrex.com> wrote:
>>
>>>There were some discussions about whether it made sense for the kernel 
>>>to support the behavior required by the RFC.  Other comments debated the 
>>>wisdom of using a tightly targeted patch specific to the RFC, or whether 
>>>a more general but intrusive solution would be better.
>>
>>I think we've made it quite clear what needs to be done for it to be
>>accepted.  All that remains is for someone to implement it.  If anyone
>>really cares about this, then please write the code instead of talking
>>about it.
> 
> 
> Okay, to confirm: you want a patch which looks at the scope value and if 
> the scope is link-local then we broadcast rather than do a directed ARP?
> 

I don't think that was the plan.  In an earlier e-mail Herbert Xu said 
(and I concur):

------------------------------
I like the idea of allowing user-space to control what addresses cause
broadcasts.  However, I'm uncomfortable with overloading existing flags
even though they might appear to fit the bill on the face of it.

People may be using this for completely different reasons (address
selection) and it's not polite to suddenly turn all their ARPs into
broadcasts.

So how about a new address flag? We still have some vacancies there.
------------------------------

The idea was to add a new flag, *not* reuse the scope value.


David Daney

Re: RFC3927 ARP patch status?

[Anand Kumria]

On Fri, Jun 02, 2006 at 05:58:27PM -0700, David Daney wrote:
> Anand Kumria wrote:
> >Herbert,
> >
> >On Sat, Jun 03, 2006 at 09:12:06AM +1000, Herbert Xu wrote:
> >
> >>David Daney <ddaney@avtrex.com> wrote:
> >>
> >>>There were some discussions about whether it made sense for the kernel 
> >>>to support the behavior required by the RFC.  Other comments debated the 
> >>>wisdom of using a tightly targeted patch specific to the RFC, or whether 
> >>>a more general but intrusive solution would be better.
> >>
> >>I think we've made it quite clear what needs to be done for it to be
> >>accepted.  All that remains is for someone to implement it.  If anyone
> >>really cares about this, then please write the code instead of talking
> >>about it.
> >
> >
> >Okay, to confirm: you want a patch which looks at the scope value and if 
> >the scope is link-local then we broadcast rather than do a directed ARP?
> >
> 
> I don't think that was the plan.  In an earlier e-mail Herbert Xu said 
> (and I concur):
> 
> ------------------------------
> I like the idea of allowing user-space to control what addresses cause
> broadcasts.  However, I'm uncomfortable with overloading existing flags
> even though they might appear to fit the bill on the face of it.
> 

[...]

Sorry, I can't find any email with any of those words in it by Herbert.
Could you tell me the message-id, so I can read some of the surrounding
context?

> 
> The idea was to add a new flag, *not* reuse the scope value.
> 

I guess it would be something set during RTM_NEWADDR (and returned by
RTM_GETADDR?). How does IFA_DIRECTEDARP sound? With a value type of int;
defaulting to 1.  When set to 0, generate a broadcast ARP for the
address.

Thanks,
Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"

Re: RFC3927 ARP patch status?

[Herbert Xu]

On Sat, Jun 03, 2006 at 12:50:02PM +1000, Anand Kumria wrote:
> 
> I guess it would be something set during RTM_NEWADDR (and returned by
> RTM_GETADDR?). How does IFA_DIRECTEDARP sound? With a value type of int;
> defaulting to 1.  When set to 0, generate a broadcast ARP for the
> address.

Address flags start with IFA_F and are in ifa_flags.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt