--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
In message pine.lnx.4.64.1308260755110.19...@shell4.bayarea.net, C. M. Heard
writes:
On Mon, 19 Aug 2013, C. M. Heard wrote:
On Tue, 6 Aug 2013, Mark Andrews wrote:
http://www.ietf.org/id/draft-andrews-6man-fragopt-01.txt
...
In answer to to the open questions, I would suggest using
In message pine.lnx.4.64.1308261732510.29...@shell4.bayarea.net, C. M. Heard
writes:
On Tue, 27 Aug 2013, Mark Andrews wrote:
In message pine.lnx.4.64.1308260755110.19...@shell4.bayarea.net,
C. M. Heard writes:
Here are some other suggestions:
- Make this a destination option
In message 2134f8430051b64f815c691a62d983180e2...@xch-blv-504.nw.nos.boeing.co
m, Templin, Fred L writes:
Hi Mark,
-Original Message-
From: Mark Andrews [mailto:ma...@isc.org]
Sent: Wednesday, August 07, 2013 4:56 PM
To: Templin, Fred L
Cc: Doug Barton; ipv6@ietf.org
Subject
In message 2134f8430051b64f815c691a62d983180e1...@xch-blv-504.nw.nos.boeing.co
m, Templin, Fred L writes:
Hi Mark,
-Original Message-
From: Mark Andrews [mailto:ma...@isc.org]
Sent: Tuesday, August 06, 2013 7:32 PM
To: Templin, Fred L
Cc: Doug Barton; ipv6@ietf.org
Subject
In message 2134f8430051b64f815c691a62d983180e1...@xch-blv-504.nw.nos.boeing.co
m, Templin, Fred L writes:
Hi Mark,
-Original Message-
From: Mark Andrews [mailto:ma...@isc.org]
Sent: Wednesday, August 07, 2013 2:54 PM
To: Templin, Fred L
Cc: Doug Barton; ipv6@ietf.org
they are doing DPI.
Making fragment sizes more even is yet another part of the issue.
Allowing tunnel entry points to re-fragment fragments is yet another
part of the solution space.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
http://www.ietf.org/id/draft-andrews-6man-fragopt-01.txt
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
IETF IPv6 working group
doesn't appear to be incrementally deployable. You need
the destination to be SEAL aware as it is a destination header not a
destination option.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
In message 20130806014122.690c43809...@drugs.dv.isc.org, Mark Andrews writes:
In message 2134f8430051b64f815c691a62d983180df...@xch-blv-504.nw.nos.boeing.
co
m, Templin, Fred L writes:
Hi Mike,
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org
In message pine.lnx.4.64.1308051910030.31...@shell4.bayarea.net, C. M.
Heard writes:
On Tue, 6 Aug 2013, Mark Andrews wrote:
SEAL however doesn't appear to be incrementally deployable. You need
the destination to be SEAL aware as it is a destination header not a
destination option
: https://www.ietf.org/mailman/listinfo/ipv6
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Mark Andrews writes:
I can write up my suggestion as a I-D. It provides the information
stateless middleware needs to pass fragments. It also helps firewalls
that decide they need to see the entire contents of packets by
providing protection to their reassembly queues.
Done.
http
list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
are:
Fernando
Fernando 1) The inability of middle-boxes to parse past the first XXX
Fernandobytes of a packet
Fernando
Fernando 2) Unavailability of the connection-id (five-tuple) in the
Fernandonon-first fragments.
I disagree -- I think Mark Andrews got it (mostly) right in his
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
IETF IPv6 working group mailing
In message 1372377611.3215.141.camel@karl, Karl Auer writes:
On Fri, 2013-06-28 at 09:31 +1000, Mark Andrews wrote:
Then add a cryptographic checksum of the original packet when fragmenting.
48 bits in a HBH should be enough.
Why HBH? Is that to prevent it being send in a fragment itself
operators
filter IPv6 fragments.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
IETF IPv6 working group mailing list
ipv6
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
In message 014201ce7208$1378c5f0$3a6a51d0$@tndh.net, Tony Hain writes:
Mark Andrews wrote:
One needs to get the L4 information the firewall/loadbalancer uses in
*each*
fragment.
This is a manufactured requirement to allow devices that can't do a full
reassembly to operate in under
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
0 packets that violated scope rules
93924 multicast packets which we don't join
Input histogram:
hop by hop: 132
TCP: 202894
UDP: 15103
fragment: 2213
ICMP6: 161573
--
Mark Andrews, ISC
1
extra octets per fragment.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--
Mark
just set TC=1 and attack the client over TCP. Yes, most clients
do correctly handle TC=1.
Mark
[1] https://datatracker.ietf.org/doc/draft-ietf-ipngwg-bsd-frag/
[2] http://tools.ietf.org/html/rfc3542
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org
malicious hosts sent with fake source addresses?
Well we know enough of them don't for reflection amplicifation attacks
to be a be a problem.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
:00
or
40:20:02:12:34:87:34:00:00
or
40:20:02:12:34:87:34:00
or
40:20:02:12:34:87:34
All appear to be legal. It would be cleaner if the
floor((prefix-len+7)/8) gave the number of octets in
the prefix field.
--
Mark Andrews
In message b9fc989e-a7cf-484e-a19c-e8ee58316...@consultant.com, Cutler James
R writes:
On Feb 5, 2013, at 10:12 PM, Mark Andrews ma...@isc.org wrote:
prefix: A variable-length field containing an IP address or the
prefix of an IP address. An IPv4-mapped address [RFC4291] =
must
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
In message 50a111fb.2060...@bfk.de, Hannes Frederic Sowa writes:
On 11/07/2012 02:30 AM, Mark Andrews wrote:
Should setting IPV6_USE_MIN_MTU to one (1) result in fragmented TCP packets?
Should setting IPV6_DONTFRAG to one (1) work on TCP sockets?
As I have not read otherwise I would treat
(1232|228)
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https
In message 1352259190.4281.104.camel@karl, Karl Auer writes:
On Wed, 2012-11-07 at 12:30 +1100, Mark Andrews wrote:
Should setting IPV6_USE_MIN_MTU to one (1) result in fragmented TCP
packets?
Should setting IPV6_DONTFRAG to one (1) work on TCP sockets?
[...]
Both options were set
In message d41807cf-b7f5-4770-8fb5-f0630aa4f...@apple.com, Stuart Cheshire wr
ites:
On 16 Jul, 2012, at 20:50, Mark Andrews wrote:
Stuart,
your mail client botched the Content-type line generation.
You may want to report it.
Content-type: image/png; x-unix-mode=0644; name
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
1440. route -n get -inet6 :: will show you
the current values.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
IETF IPv6 working group mailing
In message 4ffcdf5c.80...@m5p.com, George Mitchell writes:
On 07/10/12 21:35, Mark Andrews wrote:
In message 4ffccd9a.10...@m5p.com, George Mitchell writes:
So I was trying to browse the list of IETF mailing lists at www.ietf.org
to see who might be interested in my failures to browse
It is only Reported. I would say that it needs to be moved to
Rejected.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
See the nanog thread starting here:
http://mailman.nanog.org/pipermail/nanog/2012-May/048079.html
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
need a way to signal
that we want both stable and temporary prefixes with PD and a way
to differentiate them when advertising them via RA. DHCPv6 already
has IA_NA and IA_TA.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma
is somehow
- via the address selection table - aware of the organisations
network topology (VPN's and so).
Is this desired ?
Sure, why not? Lots of equipment won't need to know it but they are
all capable of processing.
Kind regards,
Marc Lampo
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley
different ULA but all
can reach the central servers. By the time a organisation reaches
this level of complexity they are a small ISP in their own right
and should be able to get /32.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
/24 for each
subnet except you know you won't need more than /24 ever.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
IETF IPv6 working
In message 20120319220801.964e91ead...@drugs.dv.isc.org, Mark Andrews writes:
In message 01f401cd05dc$20914df0$61b3e9d0$@la...@eurid.eu, Marc Lampo wri
te
s:
Allow me to clarify with an example.
In my IP(v4) experience, I have a customer with offices over multiple
Continents
+
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
the S bit if you make valid site prefix
lengths 1..128.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
IETF IPv6 working group mailing list
ipv6
In message 120e3724-7356-45f1-b70c-0b3081d8e...@nttv6.net, Arifumi Matsumoto
writes:
Hi,
On 2012/01/23, at 16:09, Mark Andrews wrote:
In message 43f32baa-c3cb-4214-bce7-b1cd75ec5...@nttv6.net, Arifumi Matsum
oto writes:
Mark,
thank you for your comment.
As you mention
of the addresses.
Regards,
On 2012/01/18, at 7:26, Mark Andrews wrote:
ULA need to be de-preferenced except for the local ULA prefixes.
Below is what I use in FreeBSD 8. It keeps local traffic using
fd92:7065:b8e::/48 rather than using the PA address. If you learn
a ULA destination
fe80::218:f3ff:feba:9a37%nfe0 prefixlen 64 scopeid 0x5
inet6 fd92:7065:b8e:0:218:f3ff:feba:9a37 prefixlen 64 autoconf
inet6 2001:470:1f00:820:218:f3ff:feba:9a37 prefixlen 64 autoconf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
In message 4f1633d7.7050...@gmail.com, Brian E Carpenter writes:
On 2012-01-18 11:26, Mark Andrews wrote:
ULA need to be de-preferenced except for the local ULA prefixes.
Below is what I use in FreeBSD 8. It keeps local traffic using
fd92:7065:b8e::/48 rather than using the PA address
: https://www.ietf.org/mailman/listinfo/ipv6
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
/mailman/listinfo/ipv6
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
IETF
in the path to the client, or what?
Note: I'm interested on the topic, but this one has to do more with Mark
Andrews' proposal than with mine. -- Mine is about how to improve the
state of affairs of IPv6 fragmentation. Mark's is about increasing its use.
I'm more about making DNS work reliably. We
are. It matters what good you do!
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--
Mark
group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma
In message 4ef20beb.8070...@si6networks.com, Fernando Gont writes:
Hi, Mark,
On 12/21/2011 11:02 AM, Mark Andrews wrote:
Such traffic absolutely occurs in the wild. I have three reasonably
busy name servers where this is logged as an error from the ipfw code,
e.g.
Dec 16 14:04:04
In message 4eeb66d6.7070...@si6networks.com, Fernando Gont writes:
Hi, Mark,
On 12/15/2011 10:19 PM, Mark Andrews wrote:
When thinking about this draft please consider the following:
http://tools.ietf.org/html/draft-andrews-6man-force-fragmentation-00
http://tools.ietf.org/html/draft
When thinking about this draft please consider the following:
http://tools.ietf.org/html/draft-andrews-6man-force-fragmentation-00
http://tools.ietf.org/html/draft-andrews-dnsext-udp-fragmentation-00
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
] On
Behalf Of Mark Andrews
Sent: Sunday, December 04, 2011 6:02 PM
To: Paul Hoffman
Cc: dns...@ietf.org; Olafur Gudmundsson
Subject: Re: [dnsext] draft-levine-dnsextlang-02
=20
On a similar matter I was in the process of submitting the following.
I just needed to address internal
the DNS reply arrived.
I have to admit that this may become a bit tricky if the DNS resolver is lo
cal
or if interface information is lost in some other way.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma
.
host.example.net S :: . indicates a machine that exist but is off net
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
IETF IPv6 working
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--===7419444934332968338==--
--
Mark Andrews, ISC
1
In message 1321243491.2514.99.camel@karl, Karl Auer writes:
On Mon, 2011-11-14 at 14:27 +1100, Mark Andrews wrote:
Anyone depending apon search lists that they did not set already
has a broken configuration.
I didn't say people should do these things, just that there are things
that *can
to trigger PMTU discovery.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
IETF IPv6 working group mailing list
ipv6@ietf.org
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
In message 5D36713D8A4E7348A7E10DF7437A4B920122BD2C@SZXEML506-MBS.china.huawei
.com, Sheng Jiang writes:
In message 4e447c7e.30...@gmail.com, Brian E Carpenter writes:
On 2011-08-12 11:47, Mark Andrews wrote:
I think it is make work
That's why I am only suggesting an IESG decision
group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma
In message 4e447c7e.30...@gmail.com, Brian E Carpenter writes:
On 2011-08-12 11:47, Mark Andrews wrote:
I think it is make work
That's why I am only suggesting an IESG decision, not a draft
and an RFC.
and won't change the amount of confusion.
In addition A6 allows compresssion
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
IETF IPv6 working group mailing list
ipv6
. This reduces the
probabilty of having to deal with multiple PTB packets.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
IETF IPv6 working
identify
spoofed from non-spoofed RA's. The node can learn which router is
using CGA's and automatically filter spoofed ones. By keeping a
little more state it can also automatically cleanup the side effects
from those spoofed RA's.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117
this is something that needs to be solved as it is a
non problem.
Bert
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
IETF IPv6 working group
are originating the packet
you are not forwarding.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
IETF IPv6 working group mailing list
2002::/16 mtu 1280
What are the figures when you do this? Does either of these change the
percentages?
Similarly for
route change net ::/0 mtu 1480
and
route change net ::/0 mtu 1280
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871
://www.ietf.org/mailman/listinfo/ipv6
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
In message 4bb783a3.3020...@redpill-linpro.com, Tore Anderson writes:
Hi Mark,
* Mark Andrews
You turn IPv6 on a service at a time. Turn it on for delay tolerent
services. e.g. SMTP. Turn it of for services which try different
servers quickly. e.g. DNS. Turn
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
enough information to meet both needs. We can
remove deprecated address but then we loose the ability to map.
We can keep the deprecated addresses but then we don't preference
the non deprecated address when establishing new sessions.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW
Vijay
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--
Mark Andrews, ISC
1 Seymour St
trying to be over clever here. KISS.
Mark
___
Behave mailing list
beh...@ietf.org
https://www.ietf.org/mailman/listinfo/behave
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https
developing
BIND 9 and went with address#port where address can
have a scope identifier %scope.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
In message 4a0cbd15.5080...@gmail.com, Brian E Carpenter writes:
Mark,
On 2009-05-15 12:11, Mark Andrews wrote:
...
[] is a kludge to get around protocols that had : already
embedded as a token seperator.
ISC looked at this over 10 years ago when we were developing
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--===0174434914==--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE
, IPPROTO_IP, IP_DONTFRAG,
off, sizeof(off));
}
#endif
Best Regards,=20
=A0=20
Jeffrey Dunn=20
Info Systems Eng., Lead=20
MITRE Corporation.
(301) 448-6965 (mobile)
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE
UDP replies work without using a
descriptor per address you listen on you need part's of the
advanced API.
Named uses the advanced API to get reply UDP traffic
sourced from the correct address.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW
the
functionality). And since the functionality in the adnvanced API (by
definition) isn't needed accept by fairly exotic usages, it's hard to
make the arguement that it needs to be implemented for basic
interoperability.
Thomas
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117
://www.ietf.org/mailman/listinfo/ipv6
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED
6fb5ee6273a57a2d597e62bbc84e1a13
%
Since the Global ID in these address are to be randomly generated, there
is no way to manual assign a local ipv6 address to an interface?
Regards,
Prabhu H
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
: this sends back ICMPv6 messages. You really do want
your border routers to tell the applications/kernel that
they have choosen the wrong IPv6 source address.
Mark
Regards,
Prabhu H
On Jan 8, 2008 5:29 PM, Mark Andrews [EMAIL PROTECTED] wrote:
Hi
--On Friday, 28 September, 2007 09:48 +1000 Mark Andrews
[EMAIL PROTECTED] wrote:
...
It's not. Even without IPv6, having search domains means you
can get unexpected results. If that's not acceptable, don't
complain, but put a period behind your FQDNs.
Please state
On 27-sep-2007, at 3:33, Mark Andrews wrote:
So your issue that the results are inconsistent is certainly real.
I'd say that the best way to avoid this is not having a search domain
at all, or at the very least not several.
Which is a totally unreasonable suggestion.
It's
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
IETF IPv6 working group
On 25-sep-2007, at 2:18, Mark Andrews wrote:
You are comingling way too many things here. Let me simply conclude
that foo.example.org is the first name that is tried and since it
exists what comes back for that name is what's going to be used.
Actually it isn't specified what
.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117
Thus spake Mark Andrews [EMAIL PROTECTED]
The alternative is to renumber the entire network every time a link goes
up
or down.
No. You don't have to renumber. You just have to deprecate
the addresses associated with the downed link. This is the
sort of thing routers should
1 - 100 of 144 matches
Mail list logo
