On Wed, 24 Sep 2003, Bob Hinden wrote:
[...]
> One cut at the cascading problem is:
>
>
>
> It would be good to get some discussion on this draft. It was intended to
> meet the ND proxy part of prefix delegation, but there hasn't been very
> much discussion to date.
I think there was some
Hi All,
On Wed, 24 Sep 2003 15:59:13 -0700
Bob Hinden <[EMAIL PROTECTED]> wrote:
>
> I think it will be driven by vendors shipping products with applications
> that make good of IPv6 and that people want to run. This will give the
> home router vendors some real incentive to add IPv6 support.
Eliot,
> Eliot Lear wrote:
> DING DING IPv4-0-Meter just went off.
> Why is this an issue in v6-land, assuming you can get a v6
> consumer networking device?
My point exactly. Can Cisco/Linksys deliver a $40 IPv6 consumer device?
:-D
Hey, I'd fork out the $40 just to see it if it comes with T
Bob,
> Bob Hinden wrote:
> I figured it would be hypocritical for me to run NAT at home
> and work on IPv6 in the IETF
I don't think so. I am not ashamed of running IPv4 NAT at home and
working on IPv6; it's a matter of money.
> so I was willing to pay a bit more money.
If not indiscrete, how m
Thomas,
It's even worse than that. If you are residential user, try finding a
home router that is actually a Real Router. I've come to the
unfortunate conclusion that they no longer exist. The market
landscape has shifted dramatically. All home routers come with NAT
builtin and the functionality
Andrew,
The other issue is cascading these setups. Currently, I am unaware of a
deployed solution for automatically telling a gateway home router what it's
IPv6 network is (Haberman has written a draft, however, and there may be
others). A second issue occurs with cascading. I have built a zero
On woensdag, sep 24, 2003, at 13:31 Europe/Amsterdam, Thomas Narten
wrote:
It's even worse than that. If you are residential user, try finding a
home router that is actually a Real Router. I've come to the
unfortunate conclusion that they no longer exist. The market
landscape has shifted dramati
Thomas Narten wrote:
To get a real router would seem
to cost a lot more (i.e, low hundreds of $$). It has been suggested
that if I want a cheap router, I should go to eBay and by a used
low-end Cisco. Kind of shows how bad the situation actually is.
Maybe salvage a low-end PC with multiple NICs a
[EMAIL PROTECTED] wrote:
Pekka had raised the comment that a reference to the MLDv1
Source Address Selection
document should be added to the Node Reqirements document:
1) some comments never made it to the draft, were they
missed or rejected
for some purpose? (Example: MLDv1 Source Addres
> It's even worse than that. If you are residential user, try finding a
> home router that is actually a Real Router. I've come to the
> unfortunate conclusion that they no longer exist. The market
> landscape has shifted dramatically. All home routers come with NAT
> builtin and the functionality
FYI
To: IETF-Announce :;
Cc: [EMAIL PROTECTED]
From: The IESG <[EMAIL PROTECTED]>
Subject: Last Call: 'Multicast Listener Discovery Version 2 (MLDv2) for
IPv6' to Proposed Standard
Reply-to: [EMAIL PROTECTED]
Date: Wed, 24 Sep 2003 09:55:28 -0400
Sender: [EMAIL PROTECTED]
X-pstn-levels:
2nd try, 1st try was rejected by the list admin.
> -Original Message-
> From: Loughney John (NRC/Helsinki)
> Sent: 24 September, 2003 11:11
> To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
> Subject: RE: I-D ACTION:draft-ietf-ipv6-node-requirements-05.txt
>
>
> Hi all,
>
> Pekka had rais
Benny,
In general, I agree with your analysis.
Benny Amorsen writes:
>
> In order to reach the same ease of configuration, it would be necessary
> to make a routing protocol where a router could ask its upstream to be
> assigned a /64. The upstream would pass the request on, until the
> request i
DING DING IPv4-0-Meter just went off.
Why is this an issue in v6-land, assuming you can get a v6 consumer
networking device?
Eliot
Michel Py wrote:
Thomas,
Thomas Narten wrote:
If you are residential user, try finding a home router
that is actually a Real Router. I've come to the
unfortu
Thomas,
> Thomas Narten wrote:
> If you are residential user, try finding a home router
> that is actually a Real Router. I've come to the
> unfortunate conclusion that they no longer exist.
The $40 router never existed. Get real, there is no way to support Joe
Blow configuring a router if it sel
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 : Unique Local IPv6 Unicast Addresses
Author(s) : R. Hinden, B. Haberman
Filename
Hi all,
I have gone through Thomas' AD review comments of this document, and filed
a number of issues. Most all of them have proposed resolutions. I have sent
the individual issues to the list. The issues can be found from:
http://danforsberg.info:8080/draft-ietf-ipv6-node-requirements
> > 11. Security Considerations
>
> This section seems both too detailed and not detailed enough. Too
> detailed in that it talks about security issues related to some
> (arbitrary?) protocols like ICMPv6, but not detailed enough in that it
> is anywhere complete and doesn't mention many other pro
> Section 9 begins by saying:
>
> > 9. Router-Specific Functionality
> >
> > This section defines general host considerations for IPv6 nodes that
> > act as routers. Currently, this section does not discuss routin-
> > specific requirements.
>
> an then immediately says
>
> > 9.1.1 IPv6
> > 6.1 Transition Mechanisms
> >
> >IPv6 nodes SHOULD use native addressing instead of transition-based
> >addressing (according to the algorithms defined in RFC 3484).
>
> Is this a statement about what needs to be implemented? Or is this an
> operational statement? (This document seems
> > 5.3.1 Managed Address Configuration
>
> IMO, it doesn't make sense to talk about "implementing DHC" without
> being more specific. I suspect that all of this section is about the
> client part of DHC, not the server. It would be good to make this
> clear. Ditto for 5.3.2.
Suggested reslution
> > DNS, as described in [RFC-1034], [RFC-1035], [RFC-1886], [RFC-3152]
> > and [RFC-3363] MAY be supported. Not all nodes will need to resolve
> > names. Note that RFC 1886 is currently being updated [RFC-1886-BIS].
>
> 1886-bis has been approved by the IESG I believe...
When it gets and RF
> > 4.5.4 Default Address Selection for IPv6 - RFC3484
> >
> > Default Address Selection for IPv6 [RFC-3484] SHOULD be supported, if
> > a node has more than one IPv6 address per interface or a node has
> > more that one IPv6 interface (physical or logical) configured.
> >
> > If supported, t
Michael Thomas <[EMAIL PROTECTED]> writes:
> From my SF-centric Nexus-of-the-web-trendiod
> standpoint: for residential use (especially with
> broadband) it is simply impossible to have an
> argument about the evils of NAT.
It's even worse than that. If you are residential user, try finding a
hom
New issue: 21, see below:
> >Prefix Discovery is how hosts discover the set of address prefixes
> >that define which destinations are on-link for an attached link.
> >Prefix discovery MUST be supported for implementations. However, the
> >implementation MAY support the option of d
> >Router Discovery is how hosts locate routers that reside on an
> >attached link. Router Discovery MUST be supported for
> >implementations. However, an implementation MAY support disabling
> >this function.
>
> Why the MAY above? If there are reasons to allow this, it would be
>
> >Nodes MUST always be able to receive fragment headers. However, if it
> >does not implement path MTU discovery it may not need to send
> >fragment headers. However, nodes that do not implement transmission
> >of fragment headers need to impose a limitation to the payload size
>
As a follow-up, the IAB is looking into creating a list
for this type of discussion based on the comments made
at the open plenary in Vienna. They will announce this
list when it is active.
Regards,
Brian
Brian Haberman wrote:
All,
The chairs have noted the level of interest garnered
by the d
Hi all,
Assigned as issue 18, comments in line.
> -Original Message-
> From: ext Jari Arkko [mailto:[EMAIL PROTECTED]
> Thomas Narten wrote:
>
> >> Routers do not need to support route optimization or home agent
> >> functionality.
> >>
> >> Routers SHOULD support the generic mobil
On Tue, Sep 23, 2003 at 04:41:16PM -0400, Margaret Wasserman wrote:
>
> I'd be happy to dust off my sl-impact draft, and update it based
> on the feedback I've received so far, if folks think that would be
> useful...
Please. It's excellent to have the issues in one place (other than
embdedded
Hi all,
I think Jari's text looks right, I have added it to the issues list
as Issue17: Mobility text changes. I am going to make the changes,
as long as noone objects.
br,
John
> > And include a normative reference to the document.
> >
> >
> >>7.2 Securing Signaling between Mobile Nodes and
I definitely think so. I think it's better if the deprecation document,
which is a standards action, stays mean and lean so that it can be read
in 5 minutes, with the full details of the issues being Informational.
Brian
Margaret Wasserman wrote:
>
> At 08:57 AM 9/23/2003 +0200, Kurt Erik Lin
Keith,
[Sorry for late reply.]
2) Referral
For referral to succeed, the transferred information must give
the receiving end-point
- a means to identify the second end-point (1b)
- a means to reach the second end-point
Note that in this case the "means to reach" does not need
to be a locator.
33 matches
Mail list logo
