Christian Huitema wrote:
And before you leap into I'm never going to use the DNS, so whats the
problem? please also note that I'm not saying that putting these
addresses into the DNS is good, bad or indifferent.
What about indifferent?
Suppose that we pre-populate the ip6.arpa tree with
On 25 Jun 2007, at 10:39pm, Scott Leibrand wrote:
Apparently people are still having a hard time visualizing use
cases for ULA-C, so let me try again to lay one out:
[...]
In addition, I am likely to change ISPs over time, and I'm too
small to qualify for PI space,
It seems that if you
Leo Vegoda wrote:
On 25 Jun 2007, at 10:39pm, Scott Leibrand wrote:
Apparently people are still having a hard time visualizing use cases
for ULA-C, so let me try again to lay one out:
[...]
In addition, I am likely to change ISPs over time, and I'm too small
to qualify for PI space,
Tatuya,
OK, it's alright to say an accident, but this accident caused the
security problem because we still think if Host1 is receiving traffic
that was meant to go to Host2, it's a security problem.
You also described the other security problem case where you said, Host1
is not compliant to
Tatuya,
OK, it's alright to say an accident, but this accident caused the
security problem because we still think if Host1 is receiving traffic
that was meant to go to Host2, it's a security problem.
You also described the other security problem case where you said, Host1
is not
Why is solving the problems with a DAD change not a perfect solution ?
The problems are serious enough for deployed codebase to change. It's
not like we are asking to replace IPv6 hardware. It's a software change
for deployed code base. Anyhow, Tatuya has already said most hosts he
has tested with
Related to this topic, long time ago when the choices of
a) DAD only on link local, and not on other addresses derived
from the same id (legal on original RFC)
b) do DAD indivially on each address
were discussed, I preferred (a) (and still do), and proposed an
additional logic on hosts using
At Tue, 26 Jun 2007 10:10:19 -0400,
Hemant Singh (shemant) [EMAIL PROTECTED] wrote:
Let's focus on the problems at hand and solutions - forget delay of
2462bis I-D or what have you. Why are we referring to text in 2462bis as
an admittance that accident cases can exist when we have a solution
Why is solving the problems with a DAD change not a perfect solution ?
The problems are serious enough for deployed codebase to change. It's
not like we are asking to replace IPv6 hardware. It's a software change
for deployed code base. Anyhow, Tatuya has already said most hosts he
has tested
We originally wanted to make changes to 2462bis I-D, but since it's in
AUTH state, that may not be possible anymore.
If you want, we can let 2462bis I-D not make our proposed change, but
our security case and solution needs to be addressed in an I-D to
highlight the problem with older
On Jun 25, 2007, at 22:28, Christian Huitema wrote:
Suppose that we pre-populate the ip6.arpa tree with synthetic name
server records, so that the name server for a given ULA prefix
ula-48::/48 (ULA-C or not) always resolves to ula-48::1 (or any
other suitably chosen anycast host
IETF IPv6 Folks,
The focus of discussion has been with regards to one proposed change to
2462bis, because of its impending release status. However, this is not
the primary focus of our I-D. The primary focus is clearing up
misconceptions related to data forwarding and address resolution with
On Tue, 19 Jun 2007, Pekka Savola wrote:
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
On Thu, 21 Jun 2007, Brian E Carpenter wrote:
I see Thomas' argument for tolerating occasional use of entries in the
global DNS for ULAs - but it seems that it leads to too many complications
to be recommended. Since I'm sure the IETF isn't ready yet to endorse the
reality of split DNS
On Thu, 21 Jun 2007, james woodyatt wrote:
snip
We successfully deprecated site-local unicast addressing by painting it with
the stink of IPv4 network address translation. However, we retained the
technical consensus that unreachable nodes still need to be uniquely
addressable, and what's
... and then you are back to being bound to some IP addresses (for
your DNS) belong to someone and you might not want that at all.
Enterprises changing providers also need to change IP for
their DNS, or
simple get PI for these IP addresses. And if you get PI, why ULA-C?!
Discussions on
Paul Vixie wrote:
Apparently people are still having a hard time visualizing use cases for
ULA-C, so let me try again to lay one out:
...
thanks.
And thank you for your thoughtful and reasoned response.
So, again, I see that ULA-C is a very simple solution to fill a very useful
Thus spake Scott Leibrand [EMAIL PROTECTED]
which wouldn't be nec'y if both of these networks were in some
new kind of PI space that was allocated out of a prefix designated
by IANA for non-DFZ use. (i keep bringing the discussion back
to that point because asking IANA to designate such a
18 matches
Mail list logo
