A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance Working Group of the IETF.
Title : Neighbor Unreachability Detection is too impatient
Author(s) : Erik Nordmark
On Wed, Apr 24, 2013 at 9:52 AM, Simon Perreault <
simon.perrea...@viagenie.ca> wrote:
> Le 2013-04-24 18:46, Scott Kitterman a écrit :
>
> So from your perspective, we could remove that guidance and replace it
>> with
>> something along the lines of:
>>
>> Check_host() [that's our generic SPF va
On Wednesday, April 24, 2013 06:52:28 PM Simon Perreault wrote:
> Le 2013-04-24 18:46, Scott Kitterman a écrit :
> > So from your perspective, we could remove that guidance and replace it
> > with
> > something along the lines of:
> >
> > Check_host() [that's our generic SPF validation function na
On Wed, Apr 24, 2013 at 12:55:19PM -0400, Scott Kitterman wrote:
> Thanks. I'll use that unless Phil responds and it turns out you two need to
> argue some more.
I don't think so, that seems fine. ;-)
Indeed one would assume that guidance wrt IPv4-mapped IPv6 exists somewhere
already.
Kind reg
Could I suggest the following:
- Keep the first sentence unchanged.
- Then:
SPF implementations on IPv6 servers need to handle both
"" and "A" records. This is because clients on IPv4
mapped IPv6 addresses [RFC4291] will appear to the SPF
implementation as IPv4 clients. Complementar
On Wednesday, April 24, 2013 06:27:19 PM Simon Perreault wrote:
> Le 2013-04-24 18:09, Philipp Kern a écrit :
> > Simon,
> >
> > am Wed, Apr 24, 2013 at 05:15:37PM +0200 hast du folgendes geschrieben:
> >> I guess I just don't understand where those IPv4-mapped IPv6
> >> addresses that the SPF pro
Le 2013-04-24 18:46, Scott Kitterman a écrit :
So from your perspective, we could remove that guidance and replace it with
something along the lines of:
Check_host() [that's our generic SPF validation function name we use in the
document] should never see IPv4-mapped IPv6 addresses. The underly
Le 2013-04-24 18:22, Scott Kitterman a écrit :
on Linux, if you set bindv6only to 0 and set up a socket listening on
AF_INET6 you are able to receive IPv4 connections to that IPv6 socket. The
source IPs will be mapped into IPv4-mapped IPv6 space. This means that you
only need to setup one socket
On Wednesday, April 24, 2013 06:09:54 PM Philipp Kern wrote:
> Simon,
>
> am Wed, Apr 24, 2013 at 05:15:37PM +0200 hast du folgendes geschrieben:
> > I guess I just don't understand where those IPv4-mapped IPv6
> > addresses that the SPF process needs to check are coming from. An
> > example would
Le 2013-04-24 18:09, Philipp Kern a écrit :
Simon,
am Wed, Apr 24, 2013 at 05:15:37PM +0200 hast du folgendes geschrieben:
I guess I just don't understand where those IPv4-mapped IPv6
addresses that the SPF process needs to check are coming from. An
example would be very helpful.
on Linux, if
Simon,
am Wed, Apr 24, 2013 at 05:15:37PM +0200 hast du folgendes geschrieben:
> I guess I just don't understand where those IPv4-mapped IPv6
> addresses that the SPF process needs to check are coming from. An
> example would be very helpful.
on Linux, if you set bindv6only to 0 and set up a sock
Le 2013-04-24 17:09, Scott Kitterman a écrit :
On Wednesday, April 24, 2013 04:56:33 PM Simon Perreault wrote:
My initial thought is you should have put that in an "ip4" mechanism. Other
way around (which is the concern that caused the text to be added) if the
IPv4-mapped addresses are treated
On Wednesday, April 24, 2013 04:56:33 PM Simon Perreault wrote:
> Le 2013-04-24 16:26, Scott Kitterman a écrit :
> > The case here is #2. In SPF there are various mechanisms that can be used
> > in an SPF record to identify sources from which mail is authorized. Two
> > of these mechanisms direct
Le 2013-04-24 16:26, Scott Kitterman a écrit :
The case here is #2. In SPF there are various mechanisms that can be used in
an SPF record to identify sources from which mail is authorized. Two of these
mechanisms directly specify IP addresses. "ip4" is used to specify IPv4
addresses and "ip6"
On Wednesday, April 24, 2013 07:04:55 AM S Moonesamy wrote:
> Hi Simon,
>
> At 04:33 24-04-2013, Simon Perreault wrote:
> >I'm sorry, I've read section 5 and that still doesn't make sense to me.
>
> I share your opinion.
>
> >How does that work? Is there a NAT46 in between?
>
> That question wa
Hi Simon,
At 04:33 24-04-2013, Simon Perreault wrote:
I'm sorry, I've read section 5 and that still doesn't make sense to me.
I share your opinion.
How does that work? Is there a NAT46 in between?
That question was never discussed within the working group. My guess
is that there would hav
Hi Simon,
At 01:31 24-04-2013, Simon Perreault wrote:
I, for one, have no idea what a "client on IPv4-mapped IPv6 address"
might be. So the text doesn't look correct to me.
If you describe in a little bit more detail what the intent is, we
can help you reformulate.
Thanks for feedback.
For
Le 2013-04-24 11:54, S Moonesamy a écrit :
Hi Simon,
At 01:31 24-04-2013, Simon Perreault wrote:
I, for one, have no idea what a "client on IPv4-mapped IPv6 address"
might be. So the text doesn't look correct to me.
If you describe in a little bit more detail what the intent is, we can
help you
Le 2013-04-23 23:59, S Moonesamy a écrit :
Section 5 of draft-ietf-spfbis-4408bis-14 has the following text:
'When any mechanism fetches host addresses to compare with , when
is an IPv4, "A" records are fetched; when is an IPv6
address, "" records are fetched. SPF implementatio
19 matches
Mail list logo
