> On Wed, 27 Jul 2005 11:16:08 +1000,
> Brett Pentland <[EMAIL PROTECTED]> said:
>> 1) Ability to indicate to a host "DHCP is not available on this link",
>> with the expectation that the host won't send any DHCP messages
>>
>> 1') Some people (one person?) also wanted the ability to ind
1) Ability to indicate to a host "DHCP is not available on this link",
with the expectation that the host won't send any DHCP messages
1') Some people (one person?) also wanted the ability to indicate
to a host "a particular type of DHCPv6 (i.e., ICB or HCB) is not
available on this l
Your summary looks right to me...
- Ralph
On Tue, 2005-07-26 at 23:22 +0900, JINMEI Tatuya / 神明達哉 wrote:
> Hello,
>
> I've (re)read the whole big thread on the recent discussion about the
> RA M/O flags starting at around end of May. We even had a meta-level
> discussion about whether those fla
The updated agenda for the IPv6 working group session at the Paris
IETF. This should include missing items pointed out on the list.
Thanks,
Bob Hinden & Brian Haberman
IPv6 Chairs
Internet Protocol Version 6 WG (IPv6)
Tuesda
Stephen,
> >> > Matt Mathis in draft-ietf-pmtud-method-04.txt and Fred Templin
> >> > in draft-templin-ipvlx-02.txt.
> >>
> >> I don't really see how those apply.
> >
> > Only because from what I remember of Matt's draft, and what Fred
> > said about his, they perform some sort of MTU discovery w
> On Tue, 26 Jul 2005 17:16:46 +0200,
> Iljitsch van Beijnum <[EMAIL PROTECTED]> said:
> Can't remember HCB and ICB stand for right now, so maybe I'm missing
> some of the finer points...
> Anyway, I believe it's important that clients know that they should
> ask for addresses + othe
On 26-jul-2005, at 13:46, Perry Lorier wrote:
6. Minimise the resources used.
Agree, except that packets are cheap on a 1000 Mbps LAN, so those
don't
count much towards 6.
Packet rate however starts becoming a problem at faster speeds, at
gige
it starts becoming a problem for hosts to
Thus spake "Mark Smith" <[EMAIL PROTECTED]>
On Tue, 26 Jul 2005 13:05:31 +0200
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote:
You mean: if I hook up two hosts that support 9k jumboframes to a
cheap unmanaged 10/100 switch (all out of the box) and it doesn't
work, I have to go in and reconfigure
Iljitsch,
> > Matt Mathis in
> > draft-ietf-pmtud-method-04.txt and Fred Templin in
> > draft-templin-ipvlx-02.txt.
>
> I don't really see how those apply.
They apply in any case where IPv6-in-IPv4 virtual links
are used instead of native IPv6 links. Where are we at
in the decision process for n
Hi Mark,
It's clear that we're thinking from two very different starting
points. You want to make a few very small changes to the current way
of using jumboframes, all the while accepting all the current
limitations that make that virtually nobody uses them.
What I want to do is remove th
In your previous mail you wrote:
I think there are three ways for us.
1) Do nothing. Jumbo Frames is an illegal specification for IEEE
802.3, and there is no de facto frame size also. Wait until IEEE
will move, or a de facto standard will be made.
=> this is not accept
On 26-jul-2005, at 16:22, JINMEI Tatuya / 神明達哉 wrote:
...I'd summarize the requirements raised in the thread as follows:
1) Ability to indicate to a host "DHCP is not available on this link",
with the expectation that the host won't send any DHCP messages
1') Some people (one person?
Hello,
Particularly in the case of a dead-lock, may I ask the current status
of draft-ietf-ipv6-rfc2462bis-08.txt?
According to the I-D tracker page,
https://datatracker.ietf.org/public/pidtracker.cgi?command=search_list&search_job_owner=0&search_group_acronym=&search_status_id=&search_cur_state=
Hello,
I've (re)read the whole big thread on the recent discussion about the
RA M/O flags starting at around end of May. We even had a meta-level
discussion about whether those flags might better be removed
altogether (again!), but it looks we agreed that we need at least some
kind of indication
Hi all:
Sorry to drop in whitout anything that important to say:
jumbograms are not the same as jumboframes - the first is IPv6 (and carries a
max of 4GB data), the later is Ethernet (and it carries up to 9KB data).
So if we want to keep the discussion fine tuned, we might want not to mix up
>
> If you enable jumbo frames on end-nodes without a layer 2 infrastructure
> that supports them, then you get what you deserve - a network that won't
> work. The solution of course is go back to standard size frames or buy
> jumbo capable layer 2 infrastructure and enable it. I think it's reall
Hi Iljitsch,
On Tue, 26 Jul 2005 13:05:31 +0200
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote:
> On 26-jul-2005, at 4:41, Mark Smith wrote:
>
> > I'd like to suggest a two phased development approach, based on
> > whether
> > layer 2 can be assumed to fully support the larger MTUs or not (I
>>> 1. do not impede 1500-byte operation
>>> 2. discover and utilize jumboframe capability where possible
>>> 3. discover and utilize (close to) the maximum MTU
>>> 4. recover from sudden MTU reductions fast enough for TCP and similar
>>> to survive
>> 5. Must be fully automatic and not require any
On 26-jul-2005, at 4:41, Mark Smith wrote:
I'd like to suggest a two phased development approach, based on
whether
layer 2 can be assumed to fully support the larger MTUs or not (I
think
the following is also probably a summary of the couple of threads of
discussion in the emails of the last
On Tue, Jul 26, 2005 at 08:41:39PM +1200, Perry Lorier wrote:
>
> > I'd like to suggest a two phased development approach, based on whether
> > layer 2 can be assumed to fully support the larger MTUs or not (I think
> > the following is also probably a summary of the couple of threads of
> > discu
> I'd like to suggest a two phased development approach, based on whether
> layer 2 can be assumed to fully support the larger MTUs or not (I think
> the following is also probably a summary of the couple of threads of
> discussion in the emails of the last couple of days) :
>
> (1) Making the as
21 matches
Mail list logo
