On Wed, Oct 29, 2003 at 08:13:38AM +0200, Pekka Savola wrote:
> - there are really misbehaving DNS servers out there, which jeopardize
> your IPv4 service if you query for 's, and
> - if you have no IPv6 address, you'll waste a roundtrip or two in
> queries
> - maybe other considerati
On Wed, 29 Oct 2003, Jun-ichiro itojun Hagino wrote:
> d) obsolete AI_ADDRCONFIG. AI_ADDRCONFIG semantics is too vague, and
> way too difficult to specify (for instance, if you have IPv6 global
> unicast address and no route, is it configured?). also, even without
> AI_ADD
On Tue, 28 Oct 2003, Tony Hain wrote:
[...]
> > So, I'll conclude by a few questions to give food for thought:
> >
> > - does this seem like a problem, that is, should getaddrinfo() +
> >AI_ADDRCONFIG perform DNS queries etc. if
> >the node only has v6 link-local/loopback addresses?
Pekka Savola wrote:
> ...
> IMHO, using link-local addresses for anything except well-specified
> purposes (e.g. routing protocols, RFC2461/2, etc.) is really, really
> counter-productive
in your limited world this is undoubtedly true, but there is a wider world
out there.
> -- as you'll have to
Michel Py wrote:
> Note that p2p is not that unfriendly as of now. I just had a look at one
> of the pieces of p2p I use at home; there are some 230k users on the
^^^
> server I connect to,
^^
And the inconsistency with that statement is ???
> plus a load of other ones wi
> >
> > The alternative is to configure systems that reside on the same link
> > to have the same prefixes.
>
> there are lots of other ways to solve that problem. none of them can be
> adequately described in one sentence - there are too many cases to consider.
Point taken. There are other w
> On Tue, 28 Oct 2003 19:25:28 -0500,
> Soliman Hesham <[EMAIL PROTECTED]> said:
> So can we move forward based on this conclusion
> and not put this in 2461bis ?
I, for one, agree.
JINMEI, Tatuya
Communicat
Fred Templin wrote:
Yes. But somehow I'm worried about this, particularly when
the MTU size field in ND is 32 bits. Is there any danger that
a false claim of a large MTU size will lead to something
bad happening? Or are we relying on the sender's hardware
to not accept overly large packets for tra
>
> the "scenario" is not significantly attractive to me.
=> Completely agree with you.
> on the other
> hand, the issue with the current conceptual sending
> algorithm (fallback
> to IPv4 gets deleyed severely) is severe, so i'm all
> for the suggested
> change.
> This is a fairly straight forward issue.
>
> see: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-onlinkassumption-00.txt
>
> 2461 says in section 5.2 :
>
>Next-hop determination for a given unicast destination operates as
>follows. The sender performs a longest prefix match aga
> > > To allow the scenario mentioned above to work, hosts would
> > > have to communicate using their link-local addresses.
> > >
> > > This seems like a reasonable suggestion, any objections?
> >
> > yes. I strenously object to any expectation that ordinary
> > apps should be able to
> > > To allow the scenario mentioned above to work, hosts would
> > > have to communicate using their link-local addresses.
> > >
> > > This seems like a reasonable suggestion, any objections?
> >
> > yes. I strenously object to any expectation that ordinary apps should
> > be able to use link
> > To allow the scenario mentioned above to work, hosts would
> > have to communicate using their link-local addresses.
> >
> > This seems like a reasonable suggestion, any objections?
>
> yes. I strenously object to any expectation that ordinary
> apps should
> be able to use link-l
> > To allow the scenario mentioned above to work, hosts would
> > have to communicate using their link-local addresses.
> >
> > This seems like a reasonable suggestion, any objections?
>
> yes. I strenously object to any expectation that ordinary apps should
> be able to use link-local address
On Tue, 28 Oct 2003 21:46:44 -0500
Soliman Hesham <[EMAIL PROTECTED]> wrote:
> To allow the scenario mentioned above to work, hosts would
> have to communicate using their link-local addresses.
>
> This seems like a reasonable suggestion, any objections?
yes. I strenously object to any expecta
Folks,
This is a fairly straight forward issue.
see: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-onlinkassumption-00.txt
2461 says in section 5.2 :
Next-hop determination for a given unicast destination operates as
follows. The sender performs a longest prefix match against th
> So, I'll conclude by a few questions to give food for thought:
>
> - does this seem like a problem, that is, should getaddrinfo() +
>AI_ADDRCONFIG perform DNS queries etc. if
>the node only has v6 link-local/loopback addresses?
>
> - is getaddrinfo() + link-local addresses som
Adding MTU negotiations to 2461bis is a non-starter IMHO. The
purpose of 2461bis is to clarify issues in the existing 2461, not
add new features.
Regards,
Brian
Fred Templin wrote:
Those interested should perhaps have a look at:
http://www.ietf.org/internet-drafts/draft-iesg-vendor-extensions-0
Those interested should perhaps have a look at:
http://www.ietf.org/internet-drafts/draft-iesg-vendor-extensions-01.txt
before responding to Hesham's question. I am seeing in that
document some language that may place the bar for acceptance
quite high indeed if we were to adopt Hesham's choice #
Folks,
I've been following this discussion and trying to understand
where people want to solve it. I'm writing my personal
conclusion here and please let me know if you disagree.
First there is the question of: is this worth solving?
and if it is, can it be entirely solved here or do we
need to
Hi Tim,
Tim Chown wrote:
On Tue, Oct 28, 2003 at 09:59:20AM -0800, Christian Huitema wrote:
It worked fine when we ran it at IETF51 in London.
You do mean DHCPv6 for DNS configuration, right? Many platforms do not
support address assignment via DHCPv6...
I think the idea is for DNS resolver dis
The draft will be refreshed.
Rich has asked that I take over for him in editing the
document. I didn't get it done by the I-D deadline
but will post an issues list and a proposed -03 document
shortly.
-Dave
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Beha
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 : IPv6 Flow Label Specification
Author(s) : J. Rajahalme, A. Conta, B. Carpenter, S. Deering
All,
Below is the tentative agenda for the IPv6 WG meetings at IETF
58. Any changes, additions, or deletions should be directed to the
chairs.
Regards,
Brian & Bob
Tuesday (11/11/03) 1700-1800
--
Intro & Agenda Bashing 5 minutes
Milest
> Off the top of my head I know that RFC3493 needs to be updated since
> the IPV6_UNICAST_HOPS socket option now accepts 0 as a valid hop
> count. I really do not understand what a hop count of 0 implies and
> why we should bother updating the RFCs.
Heh, yes. I too wondered about what I should do
Dimitry Haskin wrote:
It is perfectly valid to originate packets with Hop Count set to zero. Such
packets, if received, must not be forwarded. However they should be accepted
by a receiving node to which these packets are sent to.
Is this a feature or a bug?
Fred
[EMAIL PROTECTED]
Dimitry
--
This draft has expired and I do not know what happened to it. I checked
the archives and could not find out where this is going.
draft-ietf-ipv6-router-selection-02.txt
Since this has implications on neighbor discovery it might make sense to
add this onto RFC2461bis.
Regards
Suresh
On Tue, 28 Oct 2003 [EMAIL PROTECTED] wrote:
Hi Jari/John,
That sounds fine but it is not just RFC 2460 that needs to be updated
but perhaps many others. Off the top of my head I know that RFC3493 needs
to be updated since the IPV6_UNICAST_HOPS socket option now accepts 0 as a
valid hop count.
It is perfectly valid to originate packets with Hop Count set to zero. Such
packets, if received, must not be forwarded. However they should be accepted
by a receiving node to which these packets are sent to.
Dimitry
> -Original Message-
> From: Fred Templin [mailto:[EMAIL PROTECTED]
> Se
Don't know about the sending host, but perhaps the next forwarding
hop should send an ICMPv6 parameter problem message (RFC 2463,
section 3.4) if it gets a packet with Hop Count = 0?
Trouble is, the original source of the IPv6 packet might be different
than the previous hop which made the mistake f
Jari Arkko wrote:
Erik Nordmark wrote:
> This still has the operational issue of what happens when
> I need extra ports in my office and I get a cheap 4-port hub; neither
> the IT department nor my hosts knows that this box is present and it
> might not support jumboframes.
I'd favor robustness
Erik Nordmark wrote:
No, the existing option is only usable for lowering the MTU used within
a subnet to a value lower than what the "IP over ..." RFC prescribes.
We also need a way to convey the maximum packet size that layer 2
equipment can handle. I think this should be an option that is s
On Tue, Oct 28, 2003 at 09:59:20AM -0800, Christian Huitema wrote:
> >
> > It worked fine when we ran it at IETF51 in London.
>
> You do mean DHCPv6 for DNS configuration, right? Many platforms do not
> support address assignment via DHCPv6...
I think the idea is for DNS resolver discovery... bu
Erik Nordmark wrote:
One case in which data packets could be used as probe packets
is when IPv4 is used as an L2 media for IPv6. In this case, we could
send IPv6-in-IPv4 encapsulated packets with the DF bit NOT set
in the IPv4 header expecting that the decapsulator would send us
some sort of ind
Iljitsch van Beijnum wrote:
On 28 okt 2003, at 0:12, Fred Templin wrote:
> If I hook up two boxes that can do 9000 bytes over ethernet, but the
> switch is 1500 bytes only, I had better make sure those two boxes
> stick to 1500.
Yes, I know. By "negotiate a larger MTU" I mean not only an
init
> > This keeps popping up and we don't seem to be converging. Just
before
> > reading this thread I contacted some people about trying DHCPv6 on
the
> > MSP IETF network. I have no strong preference (yet) for either
DHCPv6
> > or RA. Let's just give DHCPv6 a try.
> >
> > What do you think of this i
Erik Nordmark wrote:
If you are still seeing the document as advocating a particular solution
alternative, please send specific text change suggestions as that is not
the document's intention.
Fred,
The question in my mind is not what one would change in the
document but instead what parts
Erik Nordmark wrote:
> This still has the operational issue of what happens when
> I need extra ports in my office and I get a cheap 4-port hub; neither
> the IT department nor my hosts knows that this box is present and it
> might not support jumboframes.
I'd favor robustness a lot more than opti
I have reviewed and have the
following two comments:
a) I think it would be helpful if the document would refer to
in places where it
explains why it does not cover site-local unicast addresses.
b) I have a more serious issue with the default zone. The text says in
several places that
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 : IPv6 Node Requirements
Author(s) : J. Loughney
Filename: draft-ietf-ipv6-no
Hi Jari,
> Suresh Krishnan wrote:
> > Hi Alain,
> > Since the hop limit is analogous to TTL in IPv4 the answer should
> > be no. But you will not find the answer in RFC 2460 as this was not
> > covered in RFC 791. This should be covered in the node requirements draft
> > (draft-ietf-ipv6-no
Suresh Krishnan wrote:
Hi Alain,
Since the hop limit is analogous to TTL in IPv4 the answer should
be no. But you will not find the answer in RFC 2460 as this was not
covered in RFC 791. This should be covered in the node requirements draft
(draft-ietf-ipv6-node-requirements-06.txt) that John i
Hi Alain,
Since the hop limit is analogous to TTL in IPv4 the answer should
be no. But you will not find the answer in RFC 2460 as this was not
covered in RFC 791. This should be covered in the node requirements draft
(draft-ietf-ipv6-node-requirements-06.txt) that John is editing. I
ch
Hi,
(Cc:'ed to [EMAIL PROTECTED] as well, because this seems to have significant
impact with the IPv6 APIs as well..)
When revising my "transarch" document, I noticed another issue v6
on-by-default might cause.
If v6 is enabled by default, all the implementations I know generate the
link-local
Ronald,
> This keeps popping up and we don't seem to be converging. Just before
> reading this thread I contacted some people about trying DHCPv6 on the
> MSP IETF network. I have no strong preference (yet) for either DHCPv6
> or RA. Let's just give DHCPv6 a try.
>
> What do you think of this id
On Tue, 28 Oct 2003 11:36:58 +0100 (CET)
Erik Nordmark <[EMAIL PROTECTED]> wrote:
> Just to restate what you are saying differently so that others might understand
> it. Today with have a MTU specified in the IPv6 over foo documents.
> We have an MTU option in router advertisements that can be use
> I'm afraid I'm not bought into this one as being necessary (yet). We know
> from our physical/logical point of attachment what the largest possible
> MTU for the attached L2 media is - this is a given.
That isn't true for Ethernet. A node attaching to an Ethernet has
no (standard) way to tell wh
> No, the existing option is only usable for lowering the MTU used within
> a subnet to a value lower than what the "IP over ..." RFC prescribes.
> We also need a way to convey the maximum packet size that layer 2
> equipment can handle. I think this should be an option that is similar
> to, bu
> If you are still seeing the document as advocating a particular solution
> alternative, please send specific text change suggestions as that is not
> the document's intention.
Fred,
The question in my mind is not what one would change in the
document but instead what parts one could retain.
The
> Tony Hain wrote:
> The market doesn't pick technology for technologies sake, it
> picks tools that solve an acute problem.
Indeed.
> This means that nat will be with us until it becomes part of
> the problem that needs solving. Consumer friendly p2p is the
> obvious catalyst, so the answer to y
> One case in which data packets could be used as probe packets
> is when IPv4 is used as an L2 media for IPv6. In this case, we could
> send IPv6-in-IPv4 encapsulated packets with the DF bit NOT set
> in the IPv4 header expecting that the decapsulator would send us
> some sort of indication if it
On 28 okt 2003, at 0:12, Fred Templin wrote:
> If I hook up two boxes that can do 9000 bytes over ethernet, but the
> switch is 1500 bytes only, I had better make sure those two boxes
> stick to 1500.
Yes, I know. By "negotiate a larger MTU" I mean not only an
initial indication of how much the *
52 matches
Mail list logo
