On 2007-06-21 20:03, Paul Vixie wrote:
Scott, what feature of existing ULAs makes them unsuitable for this
usage today? In the ridiculously unlikely event of a ULA prefix clash,
this would be detected up-front when trying to set up the reverse
delegation, and then you'd simply generate a
On 2007-06-21 18:00, Scott Leibrand wrote:
...
As far as I know there's no mechanism to delegate reverse DNS for a
locally generated ULA, since there's no ownership.
Please read RFC 4193 section 4.4.
Brian
IETF IPv6
Sorry to be slightly late...
I note that 2461bis says that unrecognized options MUST
be ignored. So that means that back-level implementations
will ignore any flag bits sent with this new option. Does
that have any side-effects that should be noted?
Brian
Hi Tatuya,
Thanks for the quick review of section 5 in our new I-D. Your reading
of section 5 is correct - we have proposed both new and old
implementations to always perform DAD for any unicast address. You are
also correct that the gross change we have proposed over 2462bis is that
old
I believe the implication comes when people assume that ULA-C addresses
will be applied on hosts that need direct communication with the DFZ.
As ULA-C is non-routable then NAT or some sort of proxy would be
required.
In a network I was designing it would be a non-issue. If a host
required access
So why are we expending so much effort getting them to switch to IPv6
earlier? When IPv6 is the mainstream method of addressing they will get
swept along. If a network admin wants to drag their feet and do things
the hard way they have a right to do that. The rest of us don't need to
go out of
I would say that it if a node does not support this new option, it will
probably not support any new functionality using the extended bit field.
I am rather neutral on whether adding such text is necessary.
Regards,
Brian
Brian E Carpenter wrote:
Sorry to be slightly late...
I note that
You don't seem to understand my point. Formal compliance is
irrelevant. The IETF isn't in the business of compliance,
conformance, or commenting on commercial products. What is
out there as running code is history and words in RFCs
will not change it.
Brian
On 2007-06-22 16:23, Hemant Singh
If that's the only implication, I'm not sure it's worth
adding. It's a bit worrisome for future interoperability
(i.e. we shouldn't use this to add flags which will cause
failures if they are ignored).
Brian
On 2007-06-22 16:02, Brian Haberman wrote:
I would say that it if a node does not
Hi Brian,
IETF can only make recommendations to implementers, they cannot force
implementers to implement anything. However, IETF is the authority on
whether an implementation is compliant with an IETF specification. By
making our proposed change to 2462bis, we are saying that old
Hemant,
Your logic escapes me. Old implementations are *old*
and will continue to do whatever their code does.
No words in 2462bis or 2462ter or anywhere can change
that. I think your proposal is a no-op.
Brian
On 2007-06-22 15:05, Hemant Singh (shemant) wrote:
Hi Tatuya,
Thanks for the
-Original Message-
From: james woodyatt [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 21, 2007 6:11 PM
To: IETF IPv6 Mailing List
Subject: Re: draft-ietf-ipv6-ula-central-02.txt
On Jun 21, 2007, at 17:22, Templin, Fred L wrote
From: Scott Leibrand [mailto:[EMAIL PROTECTED]
-Original Message-
From: Kevin Kargel [mailto:[EMAIL PROTECTED]
Sent: Friday, June 22, 2007 6:18 AM
To: Templin, Fred L; Leo Vegoda; Scott Leibrand
Cc: ipv6@ietf.org
Subject: RE: draft-ietf-ipv6-ula-central-02.txt
I believe the implication comes when people assume that ULA-C
On Jun 22, 2007, at 7:38 AM, Brian E Carpenter wrote:
What is out there as running code is history and words in RFCs will
not change it.
I think his point is that a new IPv6 implementation has just been
released into the market and is not operating very well. Forget the
compliance
I couldn't agree more about less mystery and more transparency.
The use-case I am most interested in is Mobile Ad-Hoc Networks
(MANETs) in which two or more MANETs can merge (e.g., due to
mobility). If each MANET used ULA-C's, then they could inject
each others' prefixes into their IGPs with
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, June 22, 2007 10:10 AM
To: ipv6@ietf.org
Subject: RE: draft-ietf-ipv6-ula-central-02.txt
I couldn't agree more about less mystery and more transparency.
The use-case I am most interested in is
Brian E Carpenter wrote:
On 2007-06-21 18:00, Scott Leibrand wrote:
As far as I know there's no mechanism to delegate reverse DNS for a
locally generated ULA, since there's no ownership.
Please read RFC 4193 section 4.4.
As I read RFC 4193 section 4.4, it confirms my previous
Templin, Fred L wrote:
George Mitchell wrote:
Personally, I am less certain about the probability of ULA-Cs
being administered such that a collision will never happen
than I am about the unlikelyhood of a collision between
randomly assigned ULAs. -- George Mitchell
Would it make you feel more certain if the ULA-Cs were
self-generated by sites exactly as in (RFC4193, Section 3.2)
and then registered with a central authority that would
register the address as long as it is not a duplicate? I
don't think ('draft-ietf-ipv6-ula-central', Section 3.2)
Hi,
I had raised this earlier in December 2005
http://www1.ietf.org/mail-archive/web/ipv6/current/msg06020.html .
The definition of IPv6 fragment is not clear. Infact different
protocols assume it differently, example are IPsec and SIIT. I do not
have implementations to play with, however I
Would it make you feel more certain if the ULA-Cs were
self-generated by sites exactly as in (RFC4193, Section 3.2)
and then registered with a central authority that would
register the address as long as it is not a duplicate? I
don't think ('draft-ietf-ipv6-ula-central', Section 3.2)
As far as I know there's no mechanism to delegate reverse DNS for a
locally generated ULA, since there's no ownership.
Please read RFC 4193 section 4.4.
As I read RFC 4193 section 4.4, it confirms my previous understanding
that there is no mechanism (and should be no mechanism) for
Paul Vixie wrote:
As I read RFC 4193 section 4.4, it confirms my previous understanding
that there is no mechanism (and should be no mechanism) for delegating
reverse DNS for a locally generated ULA. To my mind, this is a reason
for adopting draft-ietf-ipv6-ula-central-02.txt: the
Vishwas Manral wrote:
Hi,
I had raised this earlier in December 2005
http://www1.ietf.org/mail-archive/web/ipv6/current/msg06020.html .
The definition of IPv6 fragment is not clear. Infact different
protocols assume it differently, example are IPsec and SIIT. I do not
have
[short version: why ULA-C, when there is IPv6 PI space from RIRs already?]
bill fumerola wrote:
On Fri, Jun 22, 2007 at 08:13:23PM +0100, Jeroen Massar wrote:
IMHO then again, if you are requiring reverse DNS you clearly are connecting
some way or another to the at large Internet, thus then
... It seems like a simple IETF matter to approve a version of
draft-ietf-ipv6-ula-central that directs IANA to assign portions of this
netblock to RIRs for them to use in the manner specified in the draft.
if we're all agreed on that as an approach, and we're no longer considering
asking IANA
Hi Vishwas,
I do not really see what the problem is. The M bit is required for
two reasons
1) It is required for the length calculation of the final reassembled
packet.
2) It is used for validity checking of fragment lengths (i.e. Non final
fragments must be a multiple of 8 octets in
Hi Suresh/ Vlad,
For SIIT the fragment header is used to signal the ability to
fragment, it does not state it is a fragment itself.
A fragment with offset 0 and M flag 0 is just treated as the ONLY
fragment. No harm don
But there are different policies for fragments, including some that
drop
On Jun 20, 2007, at 3:11 AM, Jeroen Massar wrote:
I think there has been hype on both sides of this question. Router
renumbering used to be VERY annoying. I've now published several
times
on the subject
Any links to the papers?
A paper which in-my-non-humble-opinion covers a lot of
On Jun 19, 2007, at 5:41 PM, Mark Andrews wrote:
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.
assuming that all prefixes are 48 bits long, fine.
[ replying to my own, so sorry... ]
On Fri, Jun 22, 2007 at 12:54:29PM -0700, bill fumerola wrote:
if we're going to actually delegate ULA-C blocks to orgs it makes sense
to also delegate reverse to them. we always say (in RIR-land) that
addressing and routing are completely different. i'd
On Thu, 21 Jun 2007 11:42:28 -0700
james woodyatt [EMAIL PROTECTED] wrote:
On Jun 21, 2007, at 11:03, Paul Vixie wrote:
mark andrews has [observed] that there is no need for the
resolution perimeter of a PTR to differ from the routing perimeter
of the IP address described by that
[ limiting my comments to the discussion surrounding section 4.1 ]
IFF ULA-C space is to exist and be registered/delegated, delegate the
reverse blocks for that space as well. we so often beat the addressing
isn't routing drum weekly. well, DNS isn't routing. DNS+ULA-C is not
an end-run around
33 matches
Mail list logo
