is no better than
anyone else’s.
Again, agreed - but if I can, with relative ease, mitigate a potential
source of that problem I'll take it :).
On 21/09/2012, at 10:02 PM, TJ trej...@gmail.com wrote:
WRT Point-to-point links (only, any multi-access link REALLY should be a
/64): For those
being if you're in fe80::/10,
you're link local, but addresses outside fe80::/64 are reserved.
Exactly right, IMHO. Link local unicast (generic, that is - any link-scoped
uni) vs link local addresses (specific, the ones required* to be on an
interface)
/TJ
/60s ... but never a /64. If you know of any /64ers, please
name-and-shame them - or atleast push them to start thinking more clearly!
/TJ
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https
wrong ... (and
welcome the conversation!)
/TJ
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
addresses).
Factoring reality in to any decision typically yields better results, yes?
More importantly - what problem are you really trying to solve? Do you
expect to have lots of collisions in this 24 bit space on a given link?
/TJ
--
/TJ
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Off the top of my head: A link that has multiple prefixes assigned to it;
perhaps a Global and a ULA or simply multiple Globals ...
/TJ
On Thu, Oct 1, 2009 at 8:00 AM, Vijayrajan ranganathan vija...@gmail.comwrote:
Hi,
Perhaps a naive question, but can somebody mention some practical use
an equivalent approach is to extend RS/RA ...
Just FWIW - IMHO that would be better than the deprecation of RAs.
(Although I personally am OK with both RAs and DHCPv6 ... I think we just
could use a cleaner definition of the M O bits and how the hosts act on
them)
/TJ
-Original Message
have a consistent, well defined behavior.
Am I missing anything fundamental here?
/TJ
PS - I totally agree with Iljitsch's the amount of people that complain
that IPv6 changes too much seems to be about the same as those that complain
that IPv6 doesn't change enough so my guess is that they got
be developed that
needs all those host bits (or, atleast - needs more than we expect ... think
things like per-sessions IP addresses and such 'craziness' :) )
Thanks!
/TJ
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Dunn, Jeffrey H.
Sent: Wednesday
to /64s and
thus -requiring- (versus enabling) you to do this type of subnetting))
/TJ
-Original Message-
From: Dunn, Jeffrey H. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 11:11 PM
To: Brian Dickson; TJ
Cc: IETF IPv6 Mailing List; Dunn, Jeffrey H.;
[EMAIL PROTECTED
-Original Message-
From: Brian Dickson [mailto:[EMAIL PROTECTED]
Subject: Re: what problem is solved by proscribing non-64 bit prefixes?
The problem, fundamentally, is one's position in a hierarchy (of IPv6
assignments or pd's).
In many markets, there is a (very) limited pool of ISPs (let
that one and only one subnet is needed
* /56 for small sites, those expected to need only a few subnets over
the next 5 years.
* /48 for larger sites
To place a preference on the /56s, or to de-pref the /64s ... or something?
/TJ
to work ...
/TJ
-Original Message-
From: Dunn, Jeffrey H. [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2008 12:00 PM
To: TJ; ipv6@ietf.org
Cc: Dunn, Jeffrey H.; [EMAIL PROTECTED]
Subject: RE: what problem is solved by proscribing non-64 bit prefixes?
TJ,
I understand that you do
base (nic'ed from another
mail in this thread) ... the IETF says that is fine, they should simply
request the space. Some have already done so.
((This concern is exactly why ARIN recommends /56s. Problem solved?))
/TJ
PS - fairly late reminder, the v4v6Coexistence interim meeting is ongoing
allocation methodology,
future scalability concerns, etc.
No bits lost, yes?
/TJ
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
sure this has been
discussed repeatedly during the last 15 years)
I hope that clarifies my position (and it is just that - me, speaking for
myself :) ).
/TJ
-Original Message-
From: Dunn, Jeffrey H. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 10:08 AM
To: TJ; ipv6@ietf.org
Exactly - (IMHO) reserving bits to ensure more widespread compatibility,
future scalability, etc. is not a loss ... in fact, I am glad we have the
bits to (cough) lose in order to accomplish those goals!
/TJ
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
when I say (IMHO) we are past the point of
feasibly changing this boundary.
(Not saying we couldn't do it, just that (IMHO) the concerns/problems
outweigh the benefits)
/TJ
IETF IPv6 working group mailing list
ipv6@ietf.org
deployment. )
/TJ
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
be debated, but the real point is - again -
that this assumption has been baked-in to so many things that changing it is
(yes, still IMHO) a Bad Thing.
/TJ
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
...
It's actually a bit ironic, one of IPv6's strengths is it's extensibility
:).
/TJ
-Original Message-
From: Alexandru Petrescu [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 12:57 PM
To: TJ
Cc: 'IETF IPv6 Mailing List'
Subject: Re: Why would anyone want to use a 64 bit
- sporting SLAAC, maybe Stateless DHCPv6 as well?
A healthy dose of stateful IPv6 firewalling, for those so inclined.
Oh, and probably the same IPv4/NAT/FW we all know and love.
Winner.
/TJ
IETF IPv6 working group mailing list
- but
always be sure the client understands the operational pain they are about to
sign up for in many cases.
/TJ
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
http://technet.microsoft.com/en-us/library/bb490861.aspx works just fine for
me ... now ... ?
/TJ
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
tom.petch
Sent: Tuesday, April 15, 2008 12:25 PM
To: Christian Huitema; ather zaidi; ipv6@ietf.org
??
ping6 ff02::1
Which should make every single host on a link answer to it.
For the rest, read the excellent paper by Steven M. Bellovin:
http://www.cs.columbia.edu/~smb/papers/v6worms.pdf
Greets,
Jeroen
/TJ
already does it . back in the day, presumably this
was a performance benefit. Now it is one less ASIC (or fewer lines of code
burned into an ASIC) needed J.
Thanks!
/TJ http://facebook.tjevans.net/
From: Rahim Choudhary [mailto:[EMAIL PROTECTED]
Sent: Monday, January 28, 2008 5:04 PM
already does it . back in the day, presumably this
was a performance benefit. Now it is one less ASIC (or fewer lines of code
burned into an ASIC) needed J.
Thanks!
/TJ http://facebook.tjevans.net/
From: Rahim Choudhary [mailto:[EMAIL PROTECTED]
Sent: Monday, January 28, 2008 5:04 PM
it then ... without breaking all of the then-current
networks/implementations ... reasonable?
For my $.02 (or less) - yes, I think it is just a bit late to revisit the
whole /64 or no /64 now ...
/TJ
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday
Rough guess - ISPs don't like the prospect of having to look at/for ext hdrs of
every packet ...
/TJ (mobile)
-Original Message-
From: Manfredi, Albert E [EMAIL PROTECTED]
To: Brian E Carpenter [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; IPv6 WG ipv6@ietf.org
Sent: 8/29/07 4:35 PM
Subject
?
5) Note that this does not preclude, nor prevent, PI (micro)allocations or
any other RIR-based allocation scheme/effort ... and that specifically,
these ULA-C addresses are not meant to be globally routable (nor to be seen
as cheap PI address space).
... just more thoughts ...
/TJ
Optimization?
Or should we fail open - permit them, including potentially
malicious Type0s?
I know that to date my recommendation has been to fail closed, block them
all if you can't be more specific ...
/TJ
(Yes - I agree, the right answer is to upgrade to something that can be
more
the participation of an Internet Society
organization?
If it isn't our problem then the original ULA RFC shouldn't have made the
provision at all.
They (correctly, IMHO) did make a provision for globally unique ULAs
(ULA-C), so actually making these usable / real is, in fact, our problem.
/TJ
of doing more granular
filtering ... but this isn't just a hypothetical situation :))
/TJ
-Original Message-
From: Guillaume Valadon / ギョーム バラドン
[mailto:[EMAIL PROTECTED]
Sent: Friday, June 15, 2007 08:29
To: [EMAIL PROTECTED]
Cc: 'IETF IPv6 Mailing List'
Subject: Re: draft-ietf-ipv6
in the DFZ - of course not, this is private address
space. (Except maybe to black-hole them ,that is)
/TJ
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
have to go to ask anything of anyone!
Isn't the whole point of ULA-C that you do, in fact, need to ask someone?
/TJ
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman
Please add me to the 'interested' list.
Thanks!
/TJ (mobile)
-Original Message-
From: Tim Enos [EMAIL PROTECTED]
To: Paul Vixie [EMAIL PROTECTED]; ipv6@ietf.org
Sent: 01/19/07 14:42
Subject: Re: reg: DHCPv6 servers
Hi Paul,
From: Paul Vixie [EMAIL PROTECTED]
Date: 2007/01/18 Thu PM 01
37 matches
Mail list logo
