In this draft it has some requirements for generating ULA-C prefixes and
then in 7.0 it requires the RIRs to publish an RFC documenting how they
will implement these requirements.
I don't think the RIRs necessarily need to publish an RFC. The main
point is for the RIRs to have sufficiently
4.1 DNS Issues
and PTR records for centrally assigned local IPv6 addresses may
be installed in the global DNS. This may be useful if these
addresses are being used for site to site or VPN style applications,
or for sites that wish to avoid separate DNS systems for inside
Thomas Narten wrote:
[..]
We have to be *very* careful here. If we allow PTR's to
be installed in the global DNS then globally reachable
nameservers *have* to exist for each prefix allocated.
Otherwise the problems that the AS112 project is trying to
deal with will
On Tue, 19 Jun 2007, Thomas Narten wrote:
And help me understand how this equates to the AS112 issues. For sites
that (today) get PI space and don't actually advertise it to the
internet, aren't the DNS issues _exactly_ the same?
IMHO, if reverse DNS is provided, it should be required that the
On Tue, 19 Jun 2007, Jeroen Massar wrote:
What is the point of that? How can a ULA address reach a global unicast
address or for that matter, how is such a ULA address, which is most likely
going to be the sole user of those reverse servers going to contact any of
the root servers, .arpa
-Original Message-
From: Jeroen Massar [mailto:[EMAIL PROTECTED]
What is the point of that? How can a ULA address reach a
global unicast
address or for that matter, how is such a ULA address, which
is most likely
going to be the sole user of those reverse servers going to
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Version 6 Working Group Working Group of
the IETF.
Title : Centrally Assigned Unique Local IPv6 Unicast Addresses
Author(s) : R. Hinden, et al.
Jeoren, what about this quote from the draft:
Sorry I mutilated your name again!
Jeroen.
Bert
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
I fail to see the point of mandating non-routable space with allocated
ULA-C. Any network administrator has the ability and freedom to not
route as much or as little of their PI space as they want. Why force
constraints on usage?
If they are going to link two physically seperated sites (into a
On Tue, Jun 19, 2007 at 04:54:36PM +0100, Jeroen Massar wrote:
When the prefix is 'local' why would that need to be rooted into the global
Internet? I get the point about having unique addresses out of the same
namespace, but I don't get why reverses then have to be supplied too.
1) by putting
Manfredi, Albert E wrote:
Jeroen, what about this quote from the draft:
Sorry I mutilated your name again!
Don't worry about that, that happens everywhere (even I typo it) ;)
4.1 DNS Issues
and PTR records for centrally assigned local IPv6 addresses may
be installed in the
Pekka Savola [EMAIL PROTECTED] writes:
On Tue, 19 Jun 2007, Thomas Narten wrote:
And help me understand how this equates to the AS112 issues. For sites
that (today) get PI space and don't actually advertise it to the
internet, aren't the DNS issues _exactly_ the same?
IMHO, if reverse
IMHO, if reverse DNS is provided, it should be required that
the authoritative DNS servers have non-ULA addresses.
Not only that, but since the goal of ULA-C addresses is to provide
something similar to what site-local was going to be, perhaps the RIRs
should operate authoritative reverse DNS
Is the goal of this document merely to define the ULA-C address range
well enough to throw it into the lake and see if it sinks or swims? Or
is there some requirement to provide a more workable form of site-
local
addresses?
The central ULA's should to be viewed in contrast to the currently
Here's a use case for ULA-C that demonstrates its usefulness, and
demonstrates why reverse DNS for ULA-C blocks is a valuable enough
service that we shouldn't purposefully break it for the public
Internet. Let's say, for example, that I'm a very small ISP with IPv6
PA space from my
Scott Leibrand wrote:
[..]
Now, whenever anyone does a traceroute into or out of my network,
they'll see ULA-C addresses in the traceroute
Which won't work, as ULA-C's are not in the routing tables, they won't pass
uRPF checks and thus those packets of yours will get dropped to the floor.
On 20 Jun 2007, at 12:07am, Scott Leibrand wrote:
Here's a use case for ULA-C that demonstrates its usefulness, and
demonstrates why reverse DNS for ULA-C blocks is a valuable enough
service that we shouldn't purposefully break it for the public
Internet. Let's say, for example, that I'm
When you got gear you are going to attach to the internet
Which Internet? The existing IPv4 one, or a future IPv6 one?
Fred
[EMAIL PROTECTED]
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests:
Leo Vegoda wrote:
On 20 Jun 2007, at 12:07am, Scott Leibrand wrote:
Here's a use case for ULA-C that demonstrates its usefulness, and
demonstrates why reverse DNS for ULA-C blocks is a valuable enough
service that we shouldn't purposefully break it for the public
Internet. Let's say, for
Templin, Fred L wrote:
Which won't work, as ULA-C's are not in the routing tables, they won't pass
uRPF checks and thus those packets of yours will get dropped to the floor.
When you got gear you are going to attach to the internet request a PI or a
PA block and use a global unicast address.
Scott Leibrand wrote:
Templin, Fred L wrote:
Which won't work, as ULA-C's are not in the routing tables, they
won't pass
uRPF checks and thus those packets of yours will get dropped to the
floor.
When you got gear you are going to attach to the internet request a
PI or a
PA block and use
4.1 DNS Issues
and PTR records for centrally assigned local IPv6 addresses may
be installed in the global DNS. This may be useful if these
addresses are being used for site to site or VPN style applications,
or for sites that wish to avoid separate DNS systems for
Jeroen Massar wrote:
The above hosts are Internet connected and most likely will thus also
end up
talking to the Internet at one point or another. I can thus only guess that
they will be wanting to fully connect to the Internet one day and the
generic solution to that problem is NAT. We wanted
I would have thought that router renumbering should be no
harder that host renumbering. Essentially all you are
changing is the higher (/48 normally) prefix bits. All
that is required is a method to distribute the set of
prefixes in use with a set of tags
I would have thought that router renumbering should be no
harder that host renumbering. Essentially all you are
changing is the higher (/48 normally) prefix bits. All
that is required is a method to distribute the set of
prefixes in use with a set of tags
Hi,
On Jun 19, 2007, at 5:12 PM, Scott Leibrand wrote:
I think what we wanted to get rid of in IPv6 was one-to-many NAT,
also know as PAT (among other names). In IPv6, we can stick to one-
to-one NAT, which eliminates most of the nastiness we associate
with NAT in today's IPv4 world.
no renumbering event is too hard in isolation ..
BGP peers, MRTG/CRICKET monitoring, /ACL configs, syslog all come to mind
as issues/considerations for router renumbering.
and remember tht the router is the distribution engine of the set
of prefixes in use with a set of tags
This prompted a jabber discussion extracts of which follow.
X note that people who operate routers are usually all about control.
automatic renumbering is scary except maybe on the edge
marka There is no loss of control. It would still require a human to add a
prefix to the set
28 matches
Mail list logo
