Pekka Savola wrote:
Incorrect. Have you even used hosts.allow? What makes you
think it's easily hackable, instantly abusable by a vaguely
clued low-level thief?
Gee, even I could use vi. As soon as you have root access, what is your
problem? I can vi the hosts.allow file, I don't know how
Pekka Savola wrote:
Then you have to first compromise the system concerned, going
through all the other protections.
Before you hack the box to circumvent the hosts.allow you still have
to ... well, hack the box! An interesting chicken and egg problem, no?
Never heard of a joe-job from the
Pekka,
Iljitsch van Beijnum wrote:
Are you saying that we should make a clear distinction
between identifiers and locators, and not have any values
that are valid in both realms?
Pekka Nikander wrote:
Yes, in the long run.
Would that include going to identifiers that are longer than 128
Brian E Carpenter wrote:
There is no defence against misconfigured routers, except
for well configured routers elsewhere.
Pekka Savola wrote:
For example, for some services I maintain, I have:
- TCP wrappers configuration in the host/service itself,
using /etc/hosts.allow
- The local
Mark Smith wrote:
I do like the idea of autoconfiguration, but in larger networks,
it can start to work against you - your network can start doing
things behind your back that make it terrible to diagnose faults.
Indeed. Trouble is with all automated systems is that the engineer that
Jeroen Massar wrote:
My current idea puts it at the resolver level. The
application gets the 128bits identifier, which
actuall is a IPv6 address, either given out from a
special registry or simply from an /48 that is
already assigned to you. This address can be used
for both routing and
Leif Johansson wrote:
Sigh. This is almost to dumb to respond to and I'll be kicking
myself when the next stats come out ;-) It is possible to build
a good car lock (I claim) and some day someone will find the
economic incentive to do so.
Since I'm so dumb explain me why isn't the good car
Pekka,
Pekka Savola wrote:
Do you mean that folks who hijacked the address space deployed
NAT to be able to continue using their hijacked space inside
their network but do one-to-one conversion at the border?
Yes. Today it is extremely common to see this with RFC1918 addresses in
the inside,
Pekka,
Pekka Savola wrote:
1. Shouldn't we first see the requirements for site-local
replacement (and other issues) and not jump straight to the
requirements for local addressing?
Do you mean that the Hain/Templin draft is too generic, or not specific
enough?
3.1 -- Network managers have
Pekka,
Pekka Savola wrote:
What I'm trying to say is that we need to first figure out
where we need local-use applications -- and, as an interim
feature, maybe reword the current draft so that it's
apparent which current perceived local-use scenarios
require specific requirements.
This
Leif Johansson wrote:
The added protection you get from a private address space
is isn't worth the bits the configuration is stored in.
Exactly the same as saying that car locks are not worth having because
they're so easy to open that they don't stop anybody. It is true indeed
that any
If an address does not meet the needs of the application, use the
provided flag to ignore it. Trying to prevent others from using a
technology that solves their problem is simply being obstructionist.
A tactic often used to stall a technology by people or organizations
that can't deliver when
Tony Hain Wrote:
If an address does not meet the needs of the application,
use the provided flag to ignore it. Trying to prevent others
from using a technology that solves their problem is simply
being obstructionist.
Michel Py wrote:
A tactic often used to stall a technology by people
Jim Bound wrote:
What was my point of compromise for SLs in that past
discussion before this wise WG consensus deprecated
them? Ok age happens I will respond :--). PUT
CONTROLS ON THEM SO THEY DON'T EVER LEAVE A SITE AND
AGREE TO THE RULES FOR THE SITE BORDER ROUTERS. But
Jim Bound wrote:
The reason NAT got away with what it did is the users got
blind sided and then IETF got sucked into building a special
NAT working group (which I objected to at Munich) and look
at the mess we have out there today. At least to me it's a
complete mess.
I have to disagree
Jim,
Jim Bound wrote:
100% agree. I was stating the tremor before IPv4 NAT actually
happened not why they are using it. I also don't think users
are stupid but maybe far to trusting of vendors and the IETF
like MObile IPv6 WG was of IPsec :--)
What drives me nuts with you is that although
Erik Nordmark wrote:
FWIW, I think a multi6 solution with id/loc separation will
make the local addressing concerns go away.
If it provides something that is almost as good as PI.
Tony Hain wrote:
Any separation will require a mapping infrastructure to
dynamically bind the values back
Do you have any first hand experience of this happening?
I have heard the story several times, but I would like
to see something definitive.
I have seen it 10+ years ago with a batch of NE2000 clones. They were
perfect copies of the Novell model (including the logo) but they all had
the same
Jim,
Jim Bound wrote:
Valid. If it goes to RFC status will that make
you comfortable?
Nope. The very point I am trying to make is that RFC != enforcement
mechanism.
Michel.
IETF IPng Working Group Mailing List
IPng Home
Brian,
Brian E Carpenter wrote:
I think we'd be better off to simply forget
about address scope.
At last, the real question.
Well, this could be both the best thing we could do for IPv6 and the
worst thing we could do for IPv6.
It would be the best thing we could do for IPv6 because for
Brian,
Brian E Carpenter wrote:
And the fact is that enterprise network managers are
very happy to have a class of addresses that cannot be
globally routed and are filtered by default as bogons
by all ISPs.
You forget that the very reason RFC1918 addresses are filtered as bogons
is
Brian,
Brian E Carpenter
My bottom line on this, I think, is that this version
of scope has very limited use - it doesn't deal with the
situations that my services colleagues see every day,
and it is not something that middleware can make any use
of. At most, it allows for some defaults in
Brian,
Michel Py wrote:
It's a matter of risk: If I use the
Hinden/Haberman draft as private addresses, and if it ends up
being perverted as PI, my entire network design goes to the
trash. If I hijack a random prefix for private addresses, the
risk of collisions although not null is a lot
Eliot,
Eliot Lear wrote:
If you look at most of the home routers, they have more
of a notion of inside and outside interfaces.
Even the HOME router doesn't build an assumption along
the lines you are discussing. It doesn't look at the
bits in the address field, other than to NAT permitted
Tony,
Tony Hain wrote:
Insisting on a single address per interface is the only
way to avoid address selection.
There are ample comments that a lot of enterprise managers will be
favorable to that concept.
This whole discussion is about multihoming
It has always been the sticking point.
Jim,
Jim Bound wrote:
If we simply say these NEVER leave the site then
all is fine. Thats the bottom line.
Michel Py wrote.
I'm ok with that. Not only never leave the site but
making sure that they can't.
Even better yes. They can't.
You can't guarantee that for the Hinden/Haberman
Eliot,
Eliot Lear wrote:
I guess my concern is that ISPs end up routing the address
space in Bob's proposal and that we'll have another PI problem.
So while there's nothing wrong with Bob's proposal in theory
(indeed I prefer it vastly to the other SL approaches), if
customers believe they
Nir Arad wrote:
Excellent scenario, and a simple solution:
The administrator needs to define 2 address scopes.
The control device has an address in scope 1.
The host has addresses in both scopes 1 and 2, as well as a global
unicast address. The DFZ host has an address of scope 2, and a
Jim Bound wrote:
Putting on deployment hat and all this discussion from
the most knowledgeable people on this issue here SLs must
die and new pheonix is required.
Easier said than done.
But to tell a customer to use these is not honorable at
this point. My input now as individual person
Aidan Williams wrote
The current drafts look like progress to me and
remove the biggest wart of SL: ambiguity.
It's a distraction. The reason SLs are still ambiguous is because of the
deprecation process, not because ambiguity could not be removed. As a
matter of fact, this document is a
Brian,
Brian E Carpenter wrote:
Quite correct. What I'm pushing back on is the idea that three
levels of scope (link, local, global) capture much of anything
useful. If we were talking about scope between say 0 and 255,
where 0 means link, 255 means global, and 1..254 are user
defined, we
Brian,
Michel Py wrote:
Because then the addresses used on the private network would be
routable PI, which is exactly what network designers don't want
when they design a private network with private addresses.
Brian Carpenter wrote:
I still don't understand the difference between using
[EMAIL PROTECTED] wrote:
Among who? You continue to talk about consumers and how
things would be easier for them with site-locals. No
consumers are using route filtering today. No consumers
will need to use route filtering.
On which planet are you living? I have seen hundreds of consumer
Eliot Lear wrote:
The question isn't whether you *can* do it but whether
it's a good and scalable approach. There was code
*before* this debate started.
Indeed. And people were deploying before this debate started as well.
Michel.
On Behalf Of Brian E Carpenter
I think it does, because it makes less than global ambiguous.
Does it mean my intranet, my intranet plus a VPN to company
X, a VPN to company X but not my intranet, my VPNs to
companies X and Y plus a secure subset of my intranet, or a
combinatorial number of
Alain Durand wrote:
So what we have here is a case where you are multihomed
with one side that is permanently unreachable from a large
portion of the universe.
This is a feature, not a bug.
Michel.
IETF IPng Working Group
Eliot,
Eliot Lear wrote:
Subject: Geoff Huston's draft and the intended use of
the hinden/templin address space
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.
Same here, however
Mark Smith wrote:
The security paranoid, at least in an government environment,
would *like* to perform route filtering as part of a defense
in depth strategy in addition to filtering, but end-user
access requirements usually put an end to that idea.
All government networks that I have
Margaret,
Michel Py wrote:
- Whatever we can say about it, the network administrator gets
to pick what becomes of the Hinden/Haberman draft, globally
routable PI _or_ private address. The prefix can't serve both
purposes at the same time for reasons explained 20 times on
this list already
Brian,
Brian E Carpenter wrote:
I kept reading, because if these things are created they *will*
certainly end up being used as end point identifiers.
Can you develop why? In the absolute I can find lots of reasons but I
don't see why the identifier/locator solution would prefer using these
Nir,
Nir Arad wrote:
I would like to point out again, that as per my suggestion, nodes
MUST NOT send, receive or forward traffic in which the source and
destination addresses are not of the same scope.
That would some problems but appears to be unworkable to me. It's not
flexible enough.
Would you say that your network is a typical representation of
a future Joe Six- Pack network with IPv6? With the eBGP peers
and all?
A little overkill for Joe Six-Pack, but the eBGP peering is already
available for free from several providers, I don't see why it would
change for power users.
Jim,
Jim Bound wrote:
If we simply say these NEVER leave the site then all
is fine. Thats the bottom line.
I'm ok with that. Not only never leave the site but making sure that
they can't.
Michel.
IETF IPng Working Group
Tim,
Michel Py wrote:
- If globally unique IPv6 address space is free, I am willing
to give these $2.5k/yr to my ISP to announce my /48.
Tim Chown wrote:
Well, the ISP announces it, but how far does it get?
It gets to you, where you filter it but it does get to you. You filter
Brian,
Brian E Carpenter wrote:
RFC 3056 says:
[SNIP]
Now, which word in MUST NOT is hard to understand?
I think you give way too much importance to what a MUST NOT in an RFC
can achieve.
- As seen with the Elz appeal recently, the IETF is not interesting in
forcing users to configure their
Jim,
Jim Bound wrote:
But what we cannot do is discuss it for the
next year leaving the market in limbo?
The reason the market is in limbo in the first place is deprecation
without a replacement. If the market did not need SLs it would not have
gone in limbo over the issue.
Michel.
Nir Arad wrote:
I would like to point out again, that as per my suggestion, nodes
MUST NOT send, receive or forward traffic in which the source and
destination addresses are not of the same scope.
Michel Py wrote:
That would some problems but appears to be unworkable to me. It's
Tim,
Tim Chown wrote:
I like the method Alcatel use on my combined 802.11/DSL
home router. If I want to add a new wireless device for
home access, rather than having anything able to
associate, or a manual/web configuration of MAC address,
I only need press an allow association button that
[EMAIL PROTECTED] wrote:
Please describe for me what consumer networks (a home connection
to an ADSL provider for example) that have dynamic routing with
their service providers?
Mine, for example. I have a residential SBC aDSL line, single static IP,
256kbit up / 1mbit down for $49/mo which
Mans Nilsson wrote:
I fail to see why you need scoped addresses for this.
When I want my printer to stay off the net, I remove
the default route. Done.
This does not work because Joe Six-Pack does not know how to remove the
default route, so the printer will indeed acquire a default gateway
Eliot,
Eliot Lear wrote:
I was referring to the smaller devices a'la Linksys,
DNET, etc.
The first part of my post also did. When you scratch the surface it
works on an IP address basis, the rest is GUI paint to make it easy on
Joe.
With ciscos you pretty much run sed on the header
if you
Brian,
Brian E Carpenter wrote:
I don't recall that we ever promised to support scoping
of unicast addresses.
Not explicitely, but the idea about IPv6 has been since the beginning
that it would better than IPv4 with more bits (which we could have
delivered years ago). One of these things that
Michael,
For a change I mostly agree (will detail below what I don't like) with
what you just posted, especially:
Michael Thomas wrote:
so even these small sensible steps that you propose
nonetheless seem grave in their global implications.
and
But I'm sorry, if NAT's become a de-facto
Eliot / Bob,
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?
Eliot Lear wrote:
Venders speak the language of money,
So do operators and so do enterprises. Allow me to share the way
Brian,
Brian E Carpenter wrote:
Personally, I'd advise customers who believe they need local
addresses to continue using FEC0 until the addressing
architecture is revised and products catch up.
Customers don't like incertitude when designing networks and will delay
IPv6 deployment until this
Todd,
Todd T. Fries wrote:
Either you have link-local addresses, or you have
global routable addresses.
From a transit provider point of view this is true, but not for the
enterprise. There are lots of large networks that require private
addresses and use RFC1918 today. Examples that have
[SNAP]
I totally agree with the beginning of Tony's post.
Tony Hain wrote:
Until the WG agrees on the requirements, there is no
possibility for the group to evaluate the utility of
the current SL or other approaches.
I would go further than this and say that requirements alone are not
enough
Steve,
Steven M. Bellovin wrote:
Tony -- to make life easier for all concerned, please state
explicitly what recourse you're asking for from the IESG.
As things stand now, even if we agreed with everything you say,
we wouldn't know exactly what you want us to do.
IMHO the ultimate goal is
Todd,
Todd T. Fries wrote:
I understand there are tricks for faster thoroughput on
IPv4 with regards to multiple interfaces (network cards)
and a single IP address. Say, two 100mbit cards plugged
into the same 100mbit switch. Is this `trick' available
with IPv6 in any fashion?
There would
Keith Moore wrote:
Even then, there will still be cases where the right thing to do
is to talk directly to a locator. And there will also be lots
of apps for which a locator is good enough that probably
shoudn't be made dependent on the mapping service.
Agree.
So I lean towards a view
Bill Manning wrote:
ah.. perhaps my issue is that your original note
used the term production, while now you use the
term operational. they are different words w/
distinct meanings.
Would you mind sharing these meanings?
Michel.
Bill,
Bill Manning wrote:
that still does not let the IETF determine when/if any
organization has a production ipv6 service. the IETF can
define specs and recommend practice and thats as far as
it goes, IMHO.
Agree. But back to your original text:
perhaps my issue is that your original
bring RFC 3513 site-locals as a candidate scheme if you'd like,
but it loses based on ambiguity and non-portability (to name
just two) straight out of the barrel.
Loses to what? Since when requirements equates a solution?
Requirements are wishful thinking, no more. We don't throw away a
Eliot,
Michel Py wrote:
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.
Eliot Lear wrote:
It is true that we should not make standards where
Fred Templin wrote:
Loses to the proposal that best satisfies the requirements.
No more comments. The appeals will proceed as documented.
Michel.
IETF IPng Working Group Mailing List
IPng Home Page:
Fred Templin wrote:
A limited-scope addressing scheme is needed to replace the
now-deprecated site-local scheme from [RFC3513]
The site-local scheme is not deprecated until there is a published
document that states otherwise which will not happen until all the
outstanding appeals have been
Thomas,
The global routing prefix is designed to be hierarchically
structured by the RIRs and ISPs, and the subnet field is
designed to be hierarchically structured by site administrators.
Is this OK with everyone?
I'm OK with it, but I'll make a quick comment:
this is the devil's advocate
Bob,
You could as well call this draft the IPv6 swamp creation act. If these
addresses can be routed on point-to-point links or VPNs between sites,
they can be routed on the public Internet and since everyone wants
portable PI they will.
From the site's point of view, this is an easy decision:
Brian,
If you are correct, exactly the same will happen with
PA space.
[I assume that you are referring to jj's proposal]
In the putting the RIRs out of business dept, no (because LIRs would
still pay to obtain PA space).
In the explosion of the routing table dept, the risk is a lot lesser
jj wrote:
Several people such as yourself (e.g. Michele Py) have
suggested that local addresses will be advertised no
matter what.
_IF_ they have a global scope or are handled as global.
My solution simply takes the lemons and makes lemonade.
That's why I like it.
Michel.
Benny,
Benny Amorsen wrote:
It seems to me that having a global blackholed /10 is a lot
nicer to the routing table than a lot of blackholed /36's.
No argument about this, but the catch is that this /10 being blackholed
relies on the cooperation of lots of people, and this won't hold against
kre,
| Alain Durand wrote:
| Reachability os one thing, but you may have to wait for TCP timeouts.
| RFC1122, section 4.2.3.5 TCP Connection Failures
| Says that the initial SYN has to wait at least 3 minutes...
kre wrote:
You're assuming that I am actually using a TCP SYN to
detect
Kre,
Robert Elz wrote:
So, you mean there's a need to have address stability
inside the VPN?
On some, more than anything else. For example, if the VPN is used as
part of a supply chain, there are access-lists on both ends and a lot of
other manual config all over the place because this
jj,
Earlier, I suggested that an ISP could delegate addresses
out of its existing aggregated, global unicast address block
for free without providing connectivity. Having seen all of
the email on this subject, I believe that such an ISP could
actually sell prefixes for which it doesn't
Zefram,
Robert Elz wrote:
What we're lacking is any way to make a globally-scoped
non-routable address. That is, what gives us global
scoping in 2000::/3 (and most other unallocated spaces,
one presumes) is the routability - the two go hand in
hand.
Zefram wrote:
Here we're talking
Ole Troan wrote:
I agree with kre, stick to fec0::/10.
Me too. A scheme with the lower part of it for random and the upper part
of it for a fee would work too. Although this would represent only 15
prefixes per person in the long run (that's only 4 million subnet for a
family of 4, way to small
Andrew White wrote:
- A network with access to the global internet via
more than one independent path.
Pekka Savola wrote:
In some cases, it's more detailed than that, but yes.
Agree.
Andrew White wrote:
- A node with more than one usable address (having addresses
in more than one
Hans Kruse wrote:
I actually see a lot of value in the /56 proposal
I will side with Brian Carpenter on this one: we have RFC3177 and I do
not see enough reasons to re-visit it at this time.
Michel.
IETF IPng Working Group
Tim,
Michel Py wrote:
The trouble with using things such as :::/32 and
:::/32 is that they can't be configured on a router and
won't prevent the hijacking of a real prefix when labing the
case, which is what the documentation prefix tries to prevent
from happening.
Tim
Harald,
Michel Py wrote:
Example that works (WRT to being un-routable on the public
Internet that is): RFC1918. Although we occasionally see
these on the public Internet, it's due to misconfiguration.
No customer is going to see their upstream and offer them
money to leak or route RFC1918
Margaret,
Margaret Wasserman wrote:
Tony, allowing an interface to have two addresses:
- One that is globally routable and globally accessible,
and
- One that is stable and local,
is _exactly_ what I am proposing.
However, I am proposing that there is _no reason_ why
the stable,
Alex,
Alex Zinin wrote:
The problem or rather inconvenience with tieing site
boundaries and area/domain boundaries is that they
are driven by different factors. Imagine, for instance,
that your site that is currently implemented as an OSPF
area is growing so big that you need to split it
Folks,
Here is exactly why I say that this is a consensus on vaporware:
Harald Tveit Alvestrand wrote:
Note: By Deprecate Site-Local, I mean [snip]
Everyone has their own definition about what Deprecate Site-Local
means.
Michel.
Margaret,
Michel Py wrote:
Where is the doc to deprecate site-local addressing?
Margaret Wasserman wrote:
[Large snip]
It will be written if there is IETF WG consensus to
do the deprecation. I am not actually certain if
site-locals will be officially deprecated in the
separate document
Margaret,
john loughney wrote:
What is the amount of work to depreciate site locals - how
many RFCs need to be updated? I'm not convinced that
deprecating site locals really solves anything.
Margaret Wasserman wrote:
The work to keep, and finish, site-locals is much greater
than the work
Pekka,
Pekka Savola wrote:
but it depends on certain things (like site-border routers)
that are unacceptable. The proposal doesn't seem to be be
workable in practise, IMHO.
This is speculation, also called FUD and does not lead to making
progress.
I'm not personally that much opposed to
Pekka Savola wrote:
Exclusive model creates certain very disturbing problems in
hosts (wrt. oscillation between global and site-local) which
might be fixable, and ones even more so in the routers
(requiring quite extensive site-local implementation) which
is unlikely to go away.
Maybe, and
Dave / Brian,
Dave Thaler wrote:
Can someone quickly give a proposal or two for (b)
before the consensus call deadline?
It needs polishing, but FWIW:
http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-ipv6-gusl-00.txt
(not submitted to the WG)
Also read:
Margaret Wasserman wrote:
Bill Fenner, Alex Zinin, Steve Deering, Bob Hinden and I
(along with a variety of other folks) spent a long time
discussing this in various fora of the past two years,
and we have not come up with any way to ensure that the
internal path will be the shortest path
Margaret,
Michel Py wrote:
Why don't you simply make this a requirement? I have
heard many times that issue about the convexity although
I don't remember opposition to coupling the site boundaries
with the AS or routing area.
Margaret Wasserman wrote:
We probably would have... Except
Brian E Carpenter wrote:
What I raised my hand for in San Francisco was to
deprecate SL addresses as currently defined in
draft-ietf-ipngwg-addr-arch-v3-11.txt (and in RFC 2373).
This has never been stated and you can expect appeals all the way to the
supreme court and I'll be supporting
Brian E Carpenter wrote:
Exactly. It was the present incarnation, not some
possible future incarnation, that I raised my hand
against.
Really? By trying to sneak a major architectural change into a last 24
hour editorial change? I am going to file an appeal about how this
entire situation was
Michel Py wrote:
Yep. As I have said before, as long as CNN, Google, eBay,
eTrade, Yahoo and consorts are not IPv6 enabled (which
also means multihomed for these guys) IPv6 does not exist
for the general public.
Not quite: I disagree with your last statement.
Nothing stipulates that all
Margaret / Bob,
What is this consensus about? I was hoping that the mailing list would
be asked to express their opinions _after_ a text to deprecate
site-local addressing had been submitted to the working group. In the
current situation, this consensus if there is one would be good only to
Dan Lanciani wrote:
Or perhaps they implement a poor-man's multi-homing
solution to provide higher availability (though not
connection survival).
This indeed is a very common situation; T1 with DSL backup or SDSL with
cable backup, NAT+RFC1918, just change the default route in the router
and
Brian,
Brian Zill wrote:
In the case you list below, host1 and host2 will both have
two addresses. One set of those addresses share a subnet
and by virtue of longest prefix match will be the pair
picked by the source/destination address selection rules.
So host1 and host2 will happily
Brian,
Brian E Carpenter wrote:
Access control lists in routers were in use for
this years before RFC 1597. Preventing unwanted
access has never been a valid argument for private
addresses and never will be.
I have to disagree with this. There are some legitimate cases of using
private
Margaret,
Jeroen Massar wrote:
IMHO the real solution to this and some other
problems we are currently seeing in IPv6 is
really one thing which must be solved before
anything else: IPv6 Multihoming
Margaret Wasserman wrote:
I'm not sure how IPv6 Multihoming applies here.
Could you
Margaret,
Margaret Wasserman wrote:
That depends on what you mean by global reachability.
I am writing to you from behind a NAT right now.
From here, I can reach web sites on the global
Internet, etc. I can't run servers here
Why is that? (note that I am not trying do defend or condone NAT
Jeroen Massar wrote:
Nevertheless it would be great if loadbalancers sported IPv6
as it would mean that they also could handle huge sites like
CNN and Google which would be one way to allow them to upgrade
to IPv6.
Yep. As I have said before, as long as CNN, Google, eBay, eTrade, Yahoo
and
1 - 100 of 361 matches
Mail list logo
