Erik,
You listed out some of the trade-offs. The one you only inferred and
I'll be more explict about is that doing it once correctly has a benefit
of not all UDP-based applications having to reinvent the wheel (and
probably inconsistently).
Gee. I think I said this before somewhere.
Eliot
Brian E Carpenter wrote:
The other point that's been missed here is that the security-by-hiding
argument is only part of the story. Stable address space for
intermittently connected networks, unambiguous address space for VPNs,
and stable identifiers for multihoming, are also needed. Whatever you
Fred,
Fred Templin wrote:
Folks - do we have consensus to accept this document as an
IPv6 wg item (see below)?
I'll admit to some process fuzziness here, so I'm not quite sure what's
being asked. If we are being asked that we agree with the content of
the document, I'd have to say on the whole
Ronald van der Pol wrote:
Can the list be moved to a server that supports IPv6 transport? E.g.,
it looks like all the ops.ietf.org lists are delivered over IPv6 now.
Are those the words of a volunteer?
Eliot
IETF IPng Working Gr
Brian E Carpenter wrote:
That's an interesting expectation. As co-author of the planned
deprecation draft, I'd been assuming a more classical deprecation
action, in which we would simply state the previous semantics of
FEC0::/10, state that the prefix SHOULD NOT be used, but leave it
permanently as
Andrew White wrote:
This discussion is increasingly degenerating into people who say "I refuse
to believe it would ever work or why someone would want to do it" and those
who can point to working deployment scenarios.
The question isn't whether you *can* do it but whether it's a good and
scalable
Fred Templin wrote:
In the interest of not seeing this swept under the rug as you say, let's
discuss
the disconnected/intermittently-connected network case. We require stable
addressing for apps within such networks independent of what may be going
on with the provider point(s) of attachment. This
If the sole purpose of these addresses is for layer 3 connectivity as
envisioned for LOCAL USE, then I would agree with Nir Arad that we do
not have a problem. Stop reading here if that's your position.
If on the other hand, as Geoff states in his draft, and some people seem
to be implying, th
Brian,
There is a major difference between now and 1994. There should be no
hurry for anyone to NAT IPv6. If you're going to NAT IPv6 you might as
well stay on IPv4. What disturbs me most is this rush to fix something
with a solution that would derail or delay other solutions simply
because
Pekka Savola wrote:
.. but this might be.
Do all (or most) of the ISPs changing the address also provide "premium"
static IP service?
*Indeed* they do. What is interesting is that some of these "premium"
services are fabrications, and they end up changing your so-called
static IP address, anyw
Tony Hain wrote:
I don't see any content in this message.
I'll deal with this elsewhere.
Like it or not, it is accepted
security practice to limit access by filtering on bits in the IP header, and
restricting what prefixes are announced in routing protocols.
But that filtering is done EXPLICITLY
Tony Hain wrote:
Eliot Lear wrote:
Like it or not, it is accepted
security practice to limit access by filtering on bits in the IP
header, and restricting what prefixes are announced in routing
protocols.
But that filtering is done EXPLICITLY based on a PARTICULAR
device in a
PARTICULAR
Based on Ralph's analysis I vote A to support the WG's prevous decision.
That having been said, as I wrote in my previous email, I'd like to
proceed on multiple fronts to develop solutions to the underlying
problems that site-local attempted to address.
By the way, would others please state WH
Tony Hain wrote:
Assuming 'inherently' means 'well-known', yes it is true that manually
configured filtering does not *require* a well-known prefix. It is also true
that automation is required for consumers. Just because it is possible to do
manual filtering doesn't invalidate the requirement for a
Briefly (as I am short for time today):
Tony Hain wrote:
Yes, I wonder whether this could be
sufficiently handled by minimum length leases that are retained for
orders of months.
This is a business model issue and out of scope.
BCPs cover business model, but before we argue whether it's a busi
Tony,
From the operator perspective, the demand is for address space that is
architecturally set aside as private use, locally controlled. That did not
initially exist in IPv4, and history shows that people took whatever bit
patterns looked interesting.
I could see an argument for both enterprises
Michel,
I was referring to the smaller devices a'la Linksys, DNET, etc. With
ciscos you pretty much run sed on the header if you want to- not that I
think it's a good idea.
Eliot
IETF IPng Working Group Mailing List
IPng Hom
Bob Hinden wrote:
Is this sufficient? Would it better to also include an "operational
considerations" or similar section? More text on why this is important?
Bob,
Putting aside Michel's comments just for the moment, this would
seemingly be necessary, but I don't know if there is anything you c
Brian E Carpenter wrote:
Eliot,
That seems to me to be orthogonal. I agree that it would be good to see
renumbering support (maybe it's a v6ops item??). But that doesn't destroy
the value of Bob's proposal.
I guess my concern is that ISPs end up routing the address space in
Bob's proposal and th
Bob,
I am sorry, but while it is a good attempt to come up with a happy
medium between SLs and global addresses, I disagree with the approach
that draft-hinden-ipv6-global-local-addr-02.txt takes. I would prefer
an approach that makes the stability of the IP address less important
rather than
Tony Hain wrote:
There are some historic 'lessons learned' included here, but the real issue
is meeting the expectations of the network managers who are currently using
IPv4 logic. That is not to say we don't want them to change, but we can't
assume they will even be willing to consider something t
Hello,
I've read over this draft, and I find it very confusing. The title of
the draft is "Limited Range Addressing Requirements". However, as one
goes through the document, there is both justification and requirements.
What time is spent on the justification for "limited range" addressing
Michel Py wrote:
I will remind you that the official IETF position is that IPv6 is in
production, which led to the creation of the v6ops WG. IPv6 is no longer
a prototype we can tinker with. Or maybe you recommend a [graceful]
restart?
We as an organization have to be careful to not be so ossified
Michel,
> We don't throw away a
published standard with running code from multiple vendors in exchange
for the promise that _maybe_ someone will be able to produce a
replacement that meets the requirements.
It is true that we should not make standards where there is no running
code. However, Run
This has to be the most ironic timing ever. See the WG minutes as to why.
Eliot
[EMAIL PROTECTED] wrote:
A new Request for Comments is now available in online RFC libraries.
RFC 3513
Title: Internet Protocol Version 6 (IPv6) Addressing
Architecture
My mistake. I stand corrected.
Eliot
Thomas Narten wrote:
Eliot Lear <[EMAIL PROTECTED]> writes:
Network managers also don't have to expose business plans to
a registrar for evaluation for networks that are not attached to the
global Internet.
I think this is a r
[EMAIL PROTECTED] wrote:
Certainly a lot of people have tried to advance this proposition, but it
seems dubious to me. Site local addresses will neither encourage nor
discourage network address translation. And if you're going to cite
the renumbering scenario to support this idea, I suggest that
Bill, I think what your missing is that to many of us, IPv6's selling
points sum up to the following two things (the others pale):
1. Large address space
2. Mobility
(1) is not necessary with site-locals. Since we have established that
site-locals will encourage the use of NATs ('cause that's
Tony Hain wrote:
Margaret Wasserman wrote:
...
Access control is also useful, and a simple form of access
control will be needed in IPv6. However, site-local
addresses are a poor form of access control for two reasons:
- Site-local boundaries need to be at routing area
Nick,
I would question your assumptions:
a) That the existence of site locals will cause people to use NAT
b) That the deprecation of site locals will prevent people from
using NAT.
I think we have to turn this around- I view NATs as a bad thing for all
the reasons you've heard time and time ag
For those of you who are voting "no" on the question of deprecation...
I just want to reiterate something that Tony Li had mentioned (and I
hope Tony will correct me if I've lost something in the translation):
Given that if the mechanism exists we know people will develop NAT
functionality in o
Dan Lanciani wrote:
A new generation of NAT-hostile peer-to-peer applications is neither necessary
nor sufficient to eliminate NAT. Many users couldn't care less about these
wonder-apps and for those who have a legitimate need, the market will provide
a NAT-friendly alternative.
The old generation
"YES -- Deprecate site-local unicast addressing".
Short answer:
SLs need to be deprecated in favor of better tooling.
SLs as currently envisioned eliminate justification to move to IPv6.
Applications won't know how to make a proper choice.
Encourages behavior that breaks connectivity.
Elio
Tony Hain wrote:
Eliot Lear wrote:
When it's intended. However, site-local is "not the droids you're
looking for". It's not a firewall. Don't position it as such.
I did not call it a firewall, so don't put words in my mouth.
My apologies. The address
Tony Hain wrote:
Margaret Wasserman wrote:
There is a big difference between IPv6 site-local addresses
(whether "full", "moderate" or "exlusive") and the use of
private addressing behind IPv4 NATs. Without NAT, nodes that
only have an IPv6 site-local address will not be able to
communicate wi
Actually the filtering you mention in the draft set was thought of at
the time of RFC 1597. The result was that it set back ISP security
years if not decades. ISPs needed a default deny with explicit permit
model whereas site-locals and their predecessors allow for a lazy
default permit polic
vices from one of your workstations. Please read
Tony Hain's document carefully.
--
Eliot Lear
[EMAIL PROTECTED]
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
F
37 matches
Mail list logo
