If you are a Alexa Top 1M entry or host the DNS for a Alexa Top 1M
entry you should be paying attention.
I'm focusing here on unknown EDNS option handling as ISC is about
to release a version of named which will exercise these errors in
your nameservers. BIND 9.11.0 will ship with EDNS COOKIE en
I am completely innocent of rfc1812, and have been out of the game for a
long time, but I am pretty sure I was taught (and in turn taught) that a
router would reply using the address of the interface that originated
the reply unless that interface was unnumbered, in which case it would
reply
On 31/May/16 01:28, Baldur Norddahl wrote:
>>
>>
>> It goes to the USA and back again. They would need NAT64 servers in every
>> region and then let the DNS64 service decide which one is close to you by
>> encoding the region information in the returned IPv6 address. Such as
>> 2001:470:64:[regi
On Mon, 30 May 2016, Randy Bush wrote:
of course, simpletons such as i would desire the source of the time
exceeded message to be A. after all, this is the interface to which i
sent the icmp with the TTL to expire.
I agree 100%, and I'd venture to guess that most of the people running
networ
rfc1812 says
4.3.2.4 ICMP Message Source Address
Except where this document specifies otherwise, the IP source address
in an ICMP message originated by the router MUST be one of the IP
addresses associated with the physical interface over which the ICMP
message is transmitted. If
On Monday, May 30, 2016, Baldur Norddahl wrote:
> >
> > Like HE is doing?
> >
> > swmike@uplift:~$ dig +short ipv4.swm.pp.se @nat64.he.net
> > 2001:470:64:::d4f7:c88f
> > swmike@uplift:~$ ping6 2001:470:64:::d4f7:c88f
> > PING 2001:470:64:::d4f7:c88f(2001:470:64:::d4f7:c88f)
>
> Like HE is doing?
>
> swmike@uplift:~$ dig +short ipv4.swm.pp.se @nat64.he.net
> 2001:470:64:::d4f7:c88f
> swmike@uplift:~$ ping6 2001:470:64:::d4f7:c88f
> PING 2001:470:64:::d4f7:c88f(2001:470:64:::d4f7:c88f) 56 data bytes
> 64 bytes from 2001:470:64:::d4f7:c88f: icmp_
In message , Mikael Abrah
amsson writes:
> On Mon, 30 May 2016, Hugo Slabbert wrote:
>
> > ...so specifically regarding the idea of a public, anycast NAT64 service,
> > rather than the public DNS64 service Google is doing.
>
> Like HE is doing?
>
> swmike@uplift:~$ dig +short ipv4.swm.pp.
On Mon, 30 May 2016, Hugo Slabbert wrote:
...so specifically regarding the idea of a public, anycast NAT64 service,
rather than the public DNS64 service Google is doing.
Like HE is doing?
swmike@uplift:~$ dig +short ipv4.swm.pp.se @nat64.he.net
2001:470:64:::d4f7:c88f
swmike@uplift:~
On Mon 2016-May-30 11:45:11 +1000, Mark Andrews wrote:
In message
, Baldur Norddahl writes:
Ok that would be a bad idea. Nat64 is not stateless so to anycast it would
be unstable.
This is not anycast NAT64. It is anycast DNS64 with the well known
64:ff9b::/96 prefix and a local NAT64 box
10 matches
Mail list logo