objective is meant to address. Another goal is to reduce the
likelihood of IID collision.
--
james woodyatt
core os networking
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
On Jul 31, 2013, at 14:03 , Brian E Carpenter
wrote:
>
> I suppose, if the MAC layer actually delivers the clashing packet to the ND
> layer.
Alas, the presence of Neighbor Discovery proxy can disrupt that mechanism.
--
james woodyatt
core os n
t. Sorry about that."
Most importantly, there are no standard replacements, and no promises ever to
produce standard replacements. What is to be done about that?
--
james woodyatt
core os networking
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
thing the draft will actually be telling people in
my position to do with legacy host stack implementations.
How to say this politely? I think this recommendation is, at best...
unnecessary.
--
james woodyatt
core os networking
l I'm saying is that if we're going to start deprecating fragment headers,
then let's make sure we are deprecating all of the things that rely on them,
and providing a standard replacement for each of them in turn.
[Insert here shopped version of classic Hyperbole And A Half Cartoo
eliable on the real-world Internet.
I hate to sound like a broken record, but I will: I look forward to reviewing a
proposal to update to Generic Packet Tunneling in IPv6 [RFC 2473] for
implementing tunnel path MTU discovery at the encapsulation layer [c.f. RFC
4821].
--
Maybe we should be moving to deprecate those too?
--
james woodyatt
core os networking
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
n IPv6 tunnels where the path MTU is less
than typical IPv4 path MTU currently requires tunnel endpoints to use IPv6
fragment headers. I guess they have to stop doing that if this RFC is published.
I'm also excited to learn about how we're going to add PLPMTUD to GRE and
tunnel-mode IPsec ESP so they have some hope of using path MTU larger than 1280
octets.
--
james woodyatt
core os networking
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
etworks to implement RFC 4821 before they configure their
routers to break ICMPv6 path MTU discovery.
--
james woodyatt
core os networking
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
as the next L3
protocol standard.
--
james woodyatt
core os networking
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
On Jun 24, 2013, at 16:12 , joel jaeggli wrote:
> On 6/24/13 3:35 PM, james woodyatt wrote:
>> On Jun 24, 2013, at 15:11 , Ronald Bonica wrote:
>>>> "Network operators MAY filter IPv6 fragments."
>>> Ack. It is a statement of fact, not an IETF imposed
fication tests would be
updated to validate conformance to this updated standard.
Please don't let anyone be confused about what is entailed for conformance to
this update of RFC 2460. This is quite a major change to the Internet Protocol
Version 6. I'm inclined to agree with othe
ation in this draft on OS X and iOS would
be keep the Net_Iface parameter in the Network Service structure in the SC
persistent store.
> Done. (this change will appear in upcoming version -08 of this document).
Awesome. Thank you.
--
james woodyatt
core os networking
On May 19, 2013, at 14:52 , Fernando Gont wrote:
> On 05/19/2013 06:27 PM, james woodyatt wrote:
>>
>> That's not the sort of assumption I want to see go unstated in a
>> Standards Track RFC. Better would be to avoid the ambiguity
>> altogether. For example,
On May 19, 2013, at 13:16 , Fernando Gont wrote:
> On 05/19/2013 04:31 PM, james woodyatt wrote:
>> I have a problem with the following set of requirements:
>>
>> The Net_Iface is a value that identifies the network interface for
>> which an IPv6 address is bein
titude in these requirements to allow for temporally
different network interfaces associated with the same network service from the
host's view to have the same identity for the purpose of generating stable
privacy addresses.
-
support for
> advancing this document should be directed to the mailing list. Editorial
> suggestions can be sent to the authors. This last call will end on 18
> October 2012.
I support.
--
james woodyatt
core os networking
-
eliberately diverges from the "SHOULD" recommendation here
in RFC 3484, despite having been derived from the KAME stack which had zeroes
as the default values here, not ones. I have yet to see a persuasive reason to
conform strictly to th
On Aug 18, 2011, at 4:49 PM, james woodyatt wrote:
>
> ...then sleep proxies will need to possess the RSA private keys for all the
> CGAs that their client hosts register with them...
Correction: I think SEND as it is currently constituted actually just breaks
sleep proxies ent
agine improving SEND with express support for sleep
proxies, but I'm guessing that the major users of SEND are people for whom the
choice to trade energy efficiency for network security doesn't usually require
very much thought.
--
james wood
proxy.
Routers serving networks comprising lots of sleeping hosts and one or more
network sleep proxies will be receiving a lot of echo requests from a small
number of link-layer addresses, i.e. the sleep proxies, as hosts enter and
leave sleeping mode. It seems like there should be an opportu
packet filter implementation-- which might be
refined in the future, one hopes, to conform fully with RFC 6092-- that treats
this behavior as a resource exhaustion attack and drops flows accordingly.
--
james woodyatt
member of technical staff, core
ropose a system to do
this:
<http://tools.ietf.org/html/draft-woodyatt-ald>
It provoked an interesting and illustrative discussion once people understood
just what ubiquitous deployment of a protocol to do this would mean for
Internet privacy.
--
james woodyatt
me
subnet anycast prefix for one of its on-link prefixes. I haven't checked,
and I don't think the IPv6 Ready certification test does either, or I would
have remembered failing it.
It would not be very hard at all to apply a patch to comply with the
requirement in RFC 2526 to refuse thos
7;t see any benefit to starting
the DHCPv6 client unless a router explicitly tells us to expect service. No
router? No need for dynamic host configuration.
--
james woodyatt
member of technical staff, core os networking
IETF IP
> wireless network were unacceptable.
Yes, and if we'd like to rehash those arguments again, then I stand ready to
defend that proposition.
--
james woodyatt
member of technical staff, core os networking
IET
On May 13, 2011, at 11:34 , Cameron Byrne wrote:
> On May 13, 2011 11:28 AM, "james woodyatt" wrote:
> >
> > Mobile hosts SHOULD implement DHCPv6 clients.
> > I wouldn't oppose elevating the requirement further still to say that
> > mobile hosts MUST
plement DHCPv6 clients.
--
james woodyatt
member of technical staff, core os networking
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
On Apr 8, 2011, at 4:00 AM, Tim Chown wrote:
>
> Maybe hextet will grow on me. I'll start using it and see what funny looks
> or comments I get
I would have preferred "hexquad" but nobody ever listens to me.
--
james woodyatt
member of technical s
re those functions any cheaper? I doubt it.
--
james woodyatt
member of technical staff, core os networking
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
e one
could be found if we really tried hard. If you want to get hideously pedantic,
you could specify a maximum discrepancy; I'm sure Timothy Winters and his crew
would just melt if you did that.
Note: another term for "low discrepancy" is "quasi-random" but I'm n
On Apr 5, 2011, at 13:36 , Thomas Narten wrote:
>
> Case in point about how we are being *extremely* loose in using the term
> "pseudo random".
I share your concern. Would replacing "pseudo-random" with "low discrepancy"
address your concerns?
--
ja
is possible. Duplicate Address Detection (DAD) is your last best
hope for civilization.
--
james woodyatt
member of technical staff, core os networking
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Reques
oxy to prevent address conflicts, and the DAD proxy is
malfunctional, then you can expect damaged network service as a result. There
is nothing special about RFC 4941 temporary addresses or RFC 3972 cryptographic
addresses in this regard.
Plan accordingly and stay calm.
--
james woodyatt
member of
v6 only translates the network prefix; it therefore doesn't
prevent global tracking of hosts that use EUI-64 interface identifiers.
--
james woodyatt
member of technical staff, core os networking
IETF IPv6 working group
me reasons.
This draft has a long struggle ahead of it, if you ask me.
--
james woodyatt
member of technical staff, core os networking
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
ity concerns almost never trump privacy concerns.
And when they do, it's usually a source of shame.
--
james woodyatt
member of technical staff, core os networking
IETF IPv6 working group mailing list
ipv6@ietf.o
On Mar 7, 2011, at 6:08 AM, RJ Atkinson wrote:
>
> Again, it is only audit, not full blown accounting or access control
> or what not. Perfection is not a requirement here.
>
> On Fri, 04 Mar 2011 15:03:09 -0800, james woodyatt wrote:
>> is probably better achieved by e
hieved by enhancing routers with the capability
to journal their neighbor discovery cache insertions to a secure repository for
offline review. That combined with authorization logs from EAPOL ought to
provide sufficient confidence for most civilian audits. Am I missing something?
--
james
to pay for the proper costs
of auditing, and if that includes the cost of requiring every host to use
DHCPv6 to obtain both temporary and persistent addresses, then that's an
adequate solution to the auditing problem without requiring any change to the
core specifications.
--
james
that claim can be regarded, but it's a claim that can be
checked.
--
james woodyatt
member of technical staff, core os networking
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
equired here. I have no useful advice for
how to do that because I'm not entirely sure I understand what this draft is
hoping to accomplish, much less how it hopes to do it.
--
james woodyatt
member of technical staff, core os networking
to be reversed. For
example, the conceptual variable would be DisablePrivacyAddrs, and the bit in
the PIO would be named the NoPrivacy flag.
--
james woodyatt
member of technical staff, core os networking
IETF IPv6 working gro
t one major family of implementations that does not support it, i.e.
Mac OS X and iOS.
--
james woodyatt
member of technical staff, core os networking
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
s to implement security functions in
packet filters integrated with routers, c.f. RFC 6092. It would be helpful if
more participants would bear this in mind, so that we don't have to keep having
discussions in which we pretend that the conflict isn't happening when it
clearly is an ong
er to inspect the upper-layer transport header, then they
can't record state that will allow packets for the *solicited* return path. In
other words, they're still forwarded, but the return path they're meant to
solicit cannot be recorded.
--
james woodyatt
member of
eflect an
IETF consensus, assuming one could be found, to the effect that no further IPv6
extension header types are expected to be defined for the rest of the
operational lifetime of the IPv6 standard.
--
james woodyatt
member of technical staff, communicati
h would be neither hop-by-hop nor
destination-oriented, as firewalls are not necessarily either hosts or routers.
--
james woodyatt
member of technical staff, communications engineering
IETF IPv6 working group mailing list
ty sure
it's the same for the other products with DHCPv6 clients.
The AirPort and Time Capsule have a DHCPv6 server, but it's stateless and the
RA messages sent on the LAN bridge have M=0 and O=1.
--
james woodyatt
member of technical staff, communications engineering
-
h, one expects that a pattern is readily apparent to
anyone who wants to find one.)
--
james woodyatt
member of technical staff, communications engineering
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
excellent
and field-proven example of such a protocol, and I hope it isn't too
controversial to suggest that it's worth looking to, at least, for inspiration.
Of course, one hopes those drafts will emerge from IESG review sometime before
the they're old enough to buy wh
to IANA would be a bad idea.
--
james woodyatt
member of technical staff, communications engineering
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
extension headers will use the GIEH
format unless and until we ever set a new standard that allows for exceptions
to be published. If we don't do that, then the value of having the GIEH is
lost.
I may have some other improvements to propose once this becomes a
database
*before* assigning any such numbers to a new extension header.
--
james woodyatt
member of technical staff, communications engineering
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
tions to claw out marginal capacity in
under-provisioned networks. Otherwise, they should ride the best-effort bus
like everyone else.
--
james woodyatt
member of technical staff, communications engineering
IETF IPv6 working group
permit nodes to silently ignore if they do not
support processing them.
The general problem of distinguishing extension headers from upper-layer
transports by a programmatic method is, I suspect, not worth the trouble that
would surely be involved in solving it.
--
james woodyatt
member of
in I-D.ietf-v6ops-cpe-simple-security, making them less of an
interference than they would otherwise be.
--
james woodyatt
member of technical staff, communications engineering
IETF IPv6 working group mailing list
ipv6@i
ded.
> - This need should have been satisfied in the original IPv6 specification.
I was present in the room for the discussion. I don't think the audience
recognized as clear a need for this draft as the nominal authors did. The
meeting adjourned moments later without the working grou
mat so that it is possible for
intermediate nodes to skip over unknown extension headers and
continue to further process the header chain if they so desire."
And look: it's expired again.
--
james woodyatt
member of technical staff,
ind his proposal.
Where he and I disagree, I think, is on the question of whether the assumptions
are *operative*. He believes they are; I believe they are not. It's *his*
train set, though, so I suppose he can break it however he wants.
--
james woodyatt
member of technical staff, commu
s: the proposed hack cannot solve the problem it intends to solve,
and it breaks other networks that work fine today. It should not be endorsed.
--
james woodyatt
member of technical staff, communications engineering
IETF IPv6
over whether or not to make such a recommendation, then that would make me
very, very happy. We could declare all such flames out of scope for the
discussion to review I-D.ietf-v6ops-cpe-simple-security. I might even consider
bribing you with cho
headers. The idea is to define
a minimal set of new requirements for defining extension headers, for
the purpose of allowing packet analyzers to identify unambiguously the
upper layer header type of IPv6 datagrams containing any and all
extension headers that may be defined in the future.
ally bad, sorry
about that" to "security is strongly recommended, no really, everybody
uses it now," and soon to "security is absolutely mandatory, we will
kidnap your family and disappear you to jail if you don't secure your
network."
I'll be sad if I h
the end admin to manage the dual-stack
universe between their SQL and web servers.
If we're going to have another round of this discussion, can all the
participants please make a solemn pledge to read RFC 3879 all the way
through and to ask the authors, who are both regular particip
On Sep 28, 2007, at 11:49, James Carlson wrote:
And it'd probably take the threat of violence to prevent them from
using manually-configured addresses (even global scope ones) if they
so choose.
Or EAPOL.
--
james woodyatt <[EMAIL PROTECTED]>
member of technical staff, com
n the same link. They're also
still free to use link-local scope IPv6 on the link.
--
james woodyatt <[EMAIL PROTECTED]>
member of technical staff, communications engineering
IETF IPv6 working group mailing li
On Sep 28, 2007, at 07:01, Alain Durand wrote:
0% stateless autoconf.
Do you mean there will be router advertisements with M=1 and one or
more prefix information options with A=0?
--
james woodyatt <[EMAIL PROTECTED]>
member of technical staff, communications engin
On Sep 26, 2007, at 03:41, David Conrad wrote:
On Sep 24, 2007, at 8:22 PM, james woodyatt wrote:
I think you miss my point. I don't care how easy it is to patch
the source code. What I can't do is force customers to upgrade
all their network nodes at once with new firmware and
On Sep 21, 2007, at 15:19, Brian Dickson wrote:
james woodyatt wrote:
Here's why I don't care what documents allow for prefixes lengths
over 64 bits: all that hardware and software already shipped to
customers that won't and can't use them.
Won't? Without modificat
ong the participants who would be expected to make
gear to comply with it.
This sounds like a fine topic for experimental research. Have fun
storming the castle.
--
james woodyatt <[EMAIL PROTECTED]>
member of technic
misinformed about
that. It's certainly not viewed with any favor among the circles
I've been in most recently.
--
james woodyatt <[EMAIL PROTECTED]>
member of technical staff, communications engineering
IETF IP
ething better than
DHCP. It's just *not* a very good hammer-- and, you know what they
say: when all you have is a hammer, everything begins to look like a
folk singer.
--
james woodyatt <[EMAIL PROTECTED]>
member of technic
continue to require RH0 to be implemented but would restrict the
functionality of RH0. [...]
I predict a draft that describes a less restrictive policy for
handling RH0 datagrams will be ignored by everyone who has already
shipped more restrictive products.
--
james woodyatt <
will be reviewed
carefully by everyone participating in the discussions about prefix
length determination in DHCP6.
--
james woodyatt <[EMAIL PROTECTED]>
member of technical staff, communications engineering
IETF
On Aug 17, 2007, at 13:22, James Carlson wrote:
james woodyatt writes:
into ManagedFlag. If the value of ManagedFlag changes from
FALSE to
TRUE, and the host is not already running the stateful address
e "on-link flag" seems to be clearly in the domain of router
function, not dynamic node configuration. Is that to be described in
the forthcoming Internet draft?
--
james woodyatt <[EMAIL PROTECTED]>
member of technical staff, communications engineering
On Aug 17, 2007, at 6:59 AM, "Templin, Fred L" <[EMAIL PROTECTED]
> wrote:
How can that happen with a DHCPv6 host? RA will always precede DHCPv6
transactions because unless the host sees an RA with M bit set the
host
will not initiate DHCPv6.
That doesn't make much sense; if a node doesn't
omplexity. Some operators have already discovered this, and they've
now stopped using DHCP as an access control mechanism.
--
james woodyatt <[EMAIL PROTECTED]>
member of technical staff, communications engineering
---
ngineering community today is poorer
for it.
--
james woodyatt <[EMAIL PROTECTED]>
member of technical staff, communications engineering
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: htt
eijnum suggests. We are
unaware of any commercial IPv6 over PPPoE service providers today,
and nobody has filed any bugs against the AirPort base station
regarding this decision.
--
james woodyatt <[EMAIL PROTECTED]>
member of technical staff,
*why* ULA-C is the preferred
alternative to RIR-PI for local routing realms that require a global
number registry service.
--
james woodyatt <[EMAIL PROTECTED]>
member of technical staff, communications engineering
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
hese concerns. Using ULAs for this purpose
instead of Provider Independent [RIR-PI] addresses has the
attraction of making it easy to prevent leakage of local prefixes
into the default-free zone of the public Internet, thereby
enforcing the requirement to pre-arrange interconnections
urance from the operators of the public Internet that their
hundreds of thousands of local networks aren't directly reachable
from the public DFZ in the event a local NOC configures a border
router improperly. Obviously, ULA-C can do that better than PI.
Is that the big driving fa
On Jul 10, 2007, at 04:38, Roger Jorgensen wrote:
On Mon, 9 Jul 2007, james woodyatt wrote:
On Jul 3, 2007, at 13:23, Stephen Sprunk wrote:
The only difference is that if there's a registry, the end-users
have someone to sue when a collision happens.
This sounds like yet another reas
On Jul 3, 2007, at 13:23, Stephen Sprunk wrote:
The only difference is that if there's a registry, the end-users
have someone to sue when a collision happens.
This sounds like yet another reason to hate ULA-C. Seriously.
--
james woodyatt <[EMAIL PROTECTED]>
member of tech
refix that IANA reserves for its own
operations. Any sites that want ULA-C prefixes without going to a
RIR need to get one from a LIR explicitly numbered by IANA. I don't
think we've established any policy for how IANA is expected to assign
LIR numbers for use when RIR=0.
rve the RIR Num field for the existing regional registries.
Registries that aren't RIRs can be assigned by IANA directly from the
RIR=0 space.
--
james woodyatt <[EMAIL PROTECTED]>
member of technical staff, communications engineering
--
On Jun 28, 2007, at 03:24, Jeroen Massar wrote:
If one *really* requires that there will be reverse that is
'automatically setup' (ignoring that you still have to do it for
the forward) then define in the draft the method that James
Woodyatt proposed of using synthesized rever
On Jun 27, 2007, at 04:09, Brian E Carpenter wrote:
On 2007-06-27 00:42, Roger Jorgensen wrote:
On Thu, 21 Jun 2007, james woodyatt wrote:
We successfully deprecated site-local unicast addressing by
painting it with the stink of IPv4 network address translation.
However, we retained the
e
to write them myself). In the process of revising RFC 4193 for the
reverse DNS magic, we should also return fc00::/8 to IANA and
eliminate the 'L' bit, which I'm on record as saying I think was a
bad idea from the start.
--
james woodyatt <[EMAIL PROTECTED]>
me
y the way, that is *NOT* a
rhetorical question. I really want to know the answer.
--
james woodyatt <[EMAIL PROTECTED]>
member of technical staff, communications engineering
IETF IPv6 working group maili
up to speed on all the latest
technical aspects of the problem. Perhaps additional energy should
be expended there toward those ends?)
--
james woodyatt <[EMAIL PROTECTED]>
member of technical staff, communications engineering
---
stery and more transparency in working group
proceedings?
--
james woodyatt <[EMAIL PROTECTED]>
member of technical staff, communications engineering
IETF IPv6 working group mailing list
ipv6@ietf.org
Administra
AT with private addresses, and they
won't [or can't] explain why the arguments in RFC 4864 and draft-ietf-
v6ops-scanning-implications-03.txt are failing to persuade them.
--
james woodyatt <[EMAIL PROTECTED]>
member of technical st
nobody seems to be able to point me toward it. If
what you really want is to have IPv6 NAT, then let's see the real
arguments for why you want that. If any of them aren't properly
addressed in RFC 4864 and draft-ietf-v6ops-scanning-
implications-03.txt, then let's figure out
On 20 Jun 2007, at 15:10, Mark Smith wrote:
On Wed, 20 Jun 2007 11:16:15 -0700 james woodyatt <[EMAIL PROTECTED]>
wrote:
I'd be more sympathetic to arguments like this if we RFC 4864 didn't
insist on recommending the deployment of stateful packet filters in
IPv6 that break mo
en for
everything at the edges of the Internet.
If people think they can make arguments for why NAT between ULA-C
addresses and PA address will solve more problems than it really
causes— given what other problems we've already bought with the RFC
4864 packet filters— then I think w
ilter at all.
If that's not possible, then the device should permit all routing
headers. More damage will be done by blocking all routing headers
than by passing routing headers with type zero through obsolescent
middleboxes.
--
james woodyatt <[EMAIL PROTECTED]>
member of te
mend blocking all routing headers. Those participants
with reasonable arguments for recommending that all routing headers
be blocked should present them.
--
james woodyatt <[EMAIL PROTECTED]>
member of technical st
1 - 100 of 105 matches
Mail list logo
