Title: RE: IPv6 w.g. Last Call on "Deprecating Site Local Addresses"
I am generally happy with the document after reviewing it. I found a number of fairly trivial nits, plus one wording query:
Section 2.3, first para - also an editorial nit in same para:
In the first para the draft says:
> On Fri, 17 Oct 2003 17:40:52 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> The attached below is a issue list to make necessary updates on
> RFC2462 (Stateless Address Autoconfiguration).
I've slightly revised the list mainly based on comments received so
far. (Some URLs do not s
As I said I would do in my 10/29/2003 note on the ipv6 list under
the subject heading: "Re: RFC 2461bis issue: MTU handling", I am
now prepared to submit a new version of my document on dynamic
MTU determination. (Please note that there are some significant
differences from the previous version.)
On Nov 9, 2003, at 3:13 PM, Bob Hinden wrote:
Alain,
If you, or the wg, thinks this avenue is worth exploring, I can write
a 2 page draft. I honestly believe that this entire issue can be
solved outside of the IETF by the RIRs without introducing anything
new/damaging in the IPv6 architecture.
UL
Alain,
If you, or the wg, thinks this avenue is worth exploring, I can write
a 2 page draft. I honestly believe that this entire issue can be
solved outside of the IETF by the RIRs without introducing anything
new/damaging in the IPv6 architecture.
ULA do not introduce a change to the IPv6 archite
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian E Carpenter wrote:
| Pekka,
|
| Leakage in the payload (i.e. a referral) is problem we will have anyway,
| e.g. if the referred address is inside a firewall. I think that problem
There are important differences between the two types of leakage tho
On Sun, Nov 09, 2003 at 02:16:10PM -0800, Alain Durand wrote:
>
> My suggestion is to let the authority in charge of administering
> the public IP address space to allocate directly address space
> from a specific bloc to whoever wants it, with no expectation that
> it will be routable and leave i
Alain Durand wrote:
>
> On Nov 9, 2003, at 1:19 PM, Brian E Carpenter wrote:
>
> > Alain Durand wrote:
> >>
> >> On Nov 3, 2003, at 5:12 PM, Christian Huitema wrote:
> >>> In the case in point, there is a significant constituency who
> >>> believes
> >>> that they need a replacement for site loca
Pekka,
Leakage in the payload (i.e. a referral) is problem we will have anyway,
e.g. if the referred address is inside a firewall. I think that problem
is unavoidable. It's true that with a fully registered PI, diagnosis is
easier.
Brian
Pekka Savola wrote:
>
> On Sun, 9 Nov 2003, Brian E Ca
Itojun,
i object to publish this document as a standard track document.
experimental would be more preferable.
I don't agree. I think this is appropriate for standards track.
unique local IPv6 unicast address avoids some problems of site-local,
but not all; there
Alain,
I think it is well worth writing such a draft. It might move this debate
forward. However, I'll point out one advantage of Hinden/Haberman
that it cannot match - the locally-assigned version of Hinden/Haberman
is instantly available when IANA assigns a prefix, without a one to two
year dela
On Sun, 9 Nov 2003, Brian E Carpenter wrote:
[...]
> > As I explain in a previous message, this last property is not verified
> > by the hinden/haberman draft, as when those addresses leak,
> > they would create untraceable problems, very similar to the one
> > caused by RFC1918 leaks today.
>
> Q
On Nov 9, 2003, at 1:24 PM, Brian E Carpenter wrote:
Alain,
Please define "real PI (by real I mean registered)". Not having seen
the
draft that defines it, I can't evaluate your argument.
The problem with the Hinden/harbeman draft is that it allocates a part
of
the public IPv6 address space for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian E Carpenter wrote:
| Alain,
|
| Please define "real PI (by real I mean registered)". Not having seen the
| draft that defines it, I can't evaluate your argument.
|
I seem to remember Kurtis making a proposal but I'm not sure if it
was written up a
On Nov 9, 2003, at 1:19 PM, Brian E Carpenter wrote:
Alain Durand wrote:
On Nov 3, 2003, at 5:12 PM, Christian Huitema wrote:
In the case in point, there is a significant constituency who
believes
that they need a replacement for site local addresses, and that
"draft-hinden" is a reasonable way t
Alain,
Please define "real PI (by real I mean registered)". Not having seen the
draft that defines it, I can't evaluate your argument.
Brian
Alain Durand wrote:
>
> On Nov 4, 2003, at 12:48 AM, Tim Chown wrote:
>
> > On Mon, Nov 03, 2003 at 10:45:07PM -0800, Alain Durand wrote:
> >>
> >> As
Alain Durand wrote:
>
> On Nov 3, 2003, at 5:12 PM, Christian Huitema wrote:
> > In the case in point, there is a significant constituency who believes
> > that they need a replacement for site local addresses, and that
> > "draft-hinden" is a reasonable way to obtain this replacement. You are
> >
Itojun,
I see your point. But, we need to give the market away to do this or
they will invent addreses. This is better than SL. Unless we believe
it is ok for users to use Experimental RFC and are renumbering is strong
enough that we can support a change later with implementations.
So for now
itojun,
Tim has replied technically.
I would object to this being published as Experimental. That would be
the worst solution, since nobody would have any idea whether it was safe
to use it. I'd rather we simply started misusing PA or, indeed, 6to4
space to solve the operational problem. In fact
Silly me!
Brian
JINMEI Tatuya / [EMAIL PROTECTED]@C#:H(B wrote:
>
> > On Thu, 06 Nov 2003 16:57:14 +0100,
> > Brian E Carpenter <[EMAIL PROTECTED]> said:
>
> > I also don't think we should rewrite all the RFCs that refer to SL.
> > I have no problem with listing them, as in
>
> > N
Yes, correct, and SL-IMPACT must not become a blocking reference.
Brian
Pekka Savola wrote:
>
> On Thu, 6 Nov 2003, Brian E Carpenter wrote:
> > Pekka, it's been a while, but my recollection is that we (the authors)
> > didn't agree and didn't see any support for your comments on the list.
>
>>From the draft tracker:
>
>https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dsearch_list&=
>search_job_owner=3D0&search_group_acronym=3Dipv6&search_status_id=3D&sear=
>ch_cur_state=3D&sub_state_id=3D6&search_filename=3D&search_rfcnumber=3D&s=
>earch_area_acronym=3D&search_button=3DSEAR
Itojun,
> what have happened to anycast-analysis draft? i believed that it is
> in IESG queue or RFC-editor queue, but it's not in
> http://www.rfc-editor.org/queue.html.
>From the draft tracker:
https://datatracker.ietf.org/public/pidtracker.cgi?command=search_list&search_job
what have happened to anycast-analysis draft? i believed that it is
in IESG queue or RFC-editor queue, but it's not in
http://www.rfc-editor.org/queue.html.
itojun
IETF IPv6 working group mailing list
[E
On Thu, 6 Nov 2003, Brian E Carpenter wrote:
> Pekka, it's been a while, but my recollection is that we (the authors)
> didn't agree and didn't see any support for your comments on the list.
>
> I could be wrong.
There was no opposition, and there was support for at least referencing
the SL-IMPA
Hi,
The doc is pretty good but needs more work The most important thing
appears to be identifying the which features we need (considering the
tradeoffs)
substantial
---
1) The impression of the document is that it's underspecified but workable.
If the goal is to make it more fun to i
On Sun, Nov 09, 2003 at 08:49:40PM +0900, Jun-ichiro itojun Hagino wrote:
>
> - it is not expected to be routable, however, it will be treated
> as if it is a global address. therefore it is likely to be leak out.
> 1.0 asserts that "even if it leaks out there's no conflict"
> > This is a IPv6 working group last call for comments on advancing the
> > following document as an Proposed Standard:
> >
> > Title : Unique Local IPv6 Unicast Addresses
> > Author(s) : R. Hinden, B. Haberman
> > Filename: draft-ietf-ipv6-unique-local-01.txt
28 matches
Mail list logo
