Hello
Isn't there any link to refer slides ?
If available, let me know it.
Regards
Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Admini
On Thu, 20 Nov 2003 15:29:14 -0800, "Claudio DeSanti"
<[EMAIL PROTECTED]> said:
> I understand that with IPv6 a bridge has no more the option to fragment
> a too big packet, as in IPv4, but I do not believe this is an issue,
> because:
> - router advertisements may announce a proper MTU over a br
I still prefer
GUPI (pronounced "guppy" like the fish) - globally unique
provider-independent
PUPI (pronounced "puppy" like a young dog) - probably unique
provider-independent
as having about the right ratio of cuteness to mnemonic power.
---
EricLKlein wrote:
> This is not the first time that I have heard that someone was willing to
> skip IPv6 because of the percieved pain and security threat that
> standards compliance would entail. But then again these are all people
> that take security and network administration very personal and
Hi Fred,
the ~64KB MTU comes from RFC 2625 (IPv4 over Fibre Channel), and one of the
goals of the IPv6 over FC specification is to keep unchanged the
encapsulation technique between IPv4 and IPv6.
I understand that with IPv6 a bridge has no more the option to fragment a
too big packet, as in I
On Thu, Nov 20, 2003 at 02:50:19PM -0500, [EMAIL PROTECTED] wrote:
>
> Upon receipt of a router advertisement with the 'M' flag set (see
> section 5.5.3 of RFC 2462), IPv6 hosts that implement DHCPv6 MUST attempt
> to use DHCPv6 to obtain both IPv6 addess(es) and other configuration
> information
On Thu, Nov 20, 2003 at 11:50:29AM -0800, Bob Hinden wrote:
>
> Please remind me why the "in the absence of a router" text is there. I am
> having a hard time thinking about a scenario where there would be a DHCP
> server, but no router. The presences of a DHCP relay agent would also need
> a
I havn't followed this discussion closely, but in my opinion
we have no business legislating anything stronger than a
MAY in relation to handling the M & O bits in received
Router Advertisements. Sorry if this goes against other
opinions, but that's the way I see it.
Fred
[EMAIL PROTECTED]
[EMAIL P
~64KB MTU L2 media, huh? Sounds interesting.
Has there been any consideration given to L2 bridging
between FiberChannel and other media such as Gbps
and 10/100 Ethernet, or are you expecting everything
between dissimilar media to go through a router?
Thanks - Fred
[EMAIL PROTECTED]
Elizabeth Rodri
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 : Management Information Base for the User Datagram Protocol
(UDP)
Author(s) : B. Fenner
> => In 6.2.7 :
>
>Routers SHOULD inspect valid Router Advertisements sent by other
>routers and verify that the routers are advertising consistent
>information on a link. Detected inconsistencies indicate
> that one or
>more routers might be misconfigured and SHOULD be logged
John,
For those IPv6 nodes that implement DHCP, those nodes MUST use DHCP
upon the receipt of a Router Advertisement with the 'M' flag set (see
section 5.5.3 of RFC2462). In addition, in the absence of a router,
IPv6 Nodes that implement DHCP MUST attempt to use DHCP.
to:
Nodes tha
> to:
>
>Nodes that implement DHCP MUST use DHCP upon the receipt of a
>Router Advertisement with the 'M' flag set (see section 5.5.3 of
>RFC2462). In addition, in the absence of a router,
>IPv6 Nodes that implement DHCP MUST attempt to use DHCP. In this
>context, 'use DH
This is a reminder that the FC over IPv6 draft is currently in IMSS working
group last call. The last call period ends on November 24 at 9pm EST.
The draft may be found at
www.ietf.org/internet-drafts/draft-ietf-imss-ipv6-over-fibre-channel-00.txt
A link to the draft may also be found at the bo
-BEGIN PGP SIGNED MESSAGE-
Chirag H. Shroff wrote:
> I have tried several times to unsubscribe too. Please remove me from
> the mail list.
> > X-Mirrored-by: <[EMAIL PROTECTED]>
> > X-SpamCatcher-Score: 1 [X]
> > X-Real-To: <[EMAIL PROTECTED]>
That is the address with which you are
I have tried several times to unsubscribe too. Please remove me from
the mail list.
Chirag
> From [EMAIL PROTECTED] Thu Nov 20 03:14:12 2003
> X-SpamCatcher-Score: 1 [X]
> X-Autogenerated: Mirror
> X-Mirrored-by: <[EMAIL PROTECTED]>
> X-SpamCatcher-Score: 1 [X]
> X-Real-To: <[EMAIL PROTECTE
Pekka - The specific text is ambiguous ... however, in John's
message of 11/20, there is a sentence later in the same paragraph:
In this context, 'use DHCP' means trying to obtain only other
configuration information through DHCP, not address(es).
That sentence clarifies the text I quoted.
-
On Thu, Nov 20, 2003 at 09:27:27AM -0500, Soliman Hesham wrote:
>
> => In 6.2.7 :
>
>Routers SHOULD inspect valid Router Advertisements sent by other
>routers and verify that the routers are advertising consistent
>information on a link. Detected inconsistencies indicate that one or
Hesham,
At 09:27 AM 11/20/2003 -0500, Soliman Hesham wrote:
> I strongly suggest the use of "Nodes" (unqualified) in the text
> about the 'O' bit:
=> To be clear, I was suggesting substitusting "Nodes (acting as hosts)".
I'm not sure if you're replying to my comment or in general.
Thanks for t
On Thu, 20 Nov 2003, Ralph Droms wrote:
> I strongly suggest the use of "Nodes" (unqualified) in the text
> about the 'O' bit:
>
> IPv6 Nodes that implement DHCP, MUST use DHCP upon
> the receipt of a Router Advertisement with the 'O' flag set (see
> section 5.5.3 of RFC2462).
>
> The
> I strongly suggest the use of "Nodes" (unqualified) in the text
> about the 'O' bit:
=> To be clear, I was suggesting substitusting "Nodes (acting as hosts)".
I'm not sure if you're replying to my comment or in general.
> However, there is some question about any discussion of "nodes" and
I strongly suggest the use of "Nodes" (unqualified) in the text
about the 'O' bit:
IPv6 Nodes that implement DHCP, MUST use DHCP upon
the receipt of a Router Advertisement with the 'O' flag set (see
section 5.5.3 of RFC2462).
There is no reason a router can't use DHCPv6 for other configura
>
> Is there a reason to differentiate between nodes acting as
> hosts here, but
> not in the paragraph describing the behavior in response to
> the 'M' bit?
=> In general, unless previously discussed and rejected for some
reason, I'd globally: s/Nodes (acting as hosts)/host
It's a bit c
Comments (mostly editorial) in line...
- Ralph
At 11:12 AM 11/20/2003 +0200, [EMAIL PROTECTED] wrote:
Hi all,
Please ignore previous mails on this topic, here is the proposed text:
thanks,
John
> > In addition, in the absence of a router,
> >IPv6 Nodes that implement DHCP MUST attempt to
> Please ignore previous mails on this topic, here is the proposed text:
the change has to be synchronized with 2462bis effort, am i right?
itojun
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative R
-BEGIN PGP SIGNED MESSAGE-
(offtopic, but this seems to be a very difficult subject for many people)
How difficult is it to unsubscribe from mailman managed mailinglists
when the bottom of every message contains (snipped from the message):
> --
Jari Arkko wrote:
[EMAIL PROTECTED] wrote:
Hi all,
The 2nd paragraph in 4.6 looks like:
If an application is going to support Source-Specific Multicast, it
"SHOULD support MLDv2 but MAY support MLDv1 and conform to the
Source-Specific Multicast overview document [RFC3569]; refer to
Sourc
Jean-Jacques Pansiot wrote:
Jari Arkko wrote:
[EMAIL PROTECTED] wrote:
Hi all,
The 2nd paragraph in 4.6 looks like:
If an application is going to support Source-Specific Multicast,
it "SHOULD support MLDv2 but MAY support MLDv1 and conform to the
Source-Specific Multicast overview documen
I agree with Jari's proposed text.
Brian
Jari Arkko wrote:
[EMAIL PROTECTED] wrote:
Hi all,
The 2nd paragraph in 4.6 looks like:
If an application is going to support Source-Specific Multicast, it
"SHOULD support MLDv2 but MAY support MLDv1 and conform to the
Source-Specific Multicast ov
Jari Arkko wrote:
[EMAIL PROTECTED] wrote:
Hi all,
The 2nd paragraph in 4.6 looks like:
If an application is going to support Source-Specific Multicast, it
"SHOULD support MLDv2 but MAY support MLDv1 and conform to the
Source-Specific Multicast overview document [RFC3569]; refer to
Source
[EMAIL PROTECTED] wrote:
Hi all,
The 2nd paragraph in 4.6 looks like:
If an application is going to support Source-Specific Multicast,
it "SHOULD support MLDv2 but MAY support MLDv1 and conform to the
Source-Specific Multicast overview document [RFC3569]; refer to
Source-Specific Multicast
John,
[EMAIL PROTECTED] wrote:
Hi all,
The 2nd paragraph in 4.6 looks like:
If an application is going to support Source-Specific Multicast,
it "SHOULD support MLDv2 but MAY support MLDv1 and conform to the
Source-Specific Multicast overview document [RFC3569]; refer to
Source-Specific M
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: 20. november 2003 09:36
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Node Req: Issue31: DHCPv6 text
Hi All,
I forgot other text that Pekka suggested, here is all of the te
Hi all,
Please ignore previous mails on this topic, here is the proposed text:
thanks,
John
> > In addition, in the absence of a router,
> >IPv6 Nodes that implement DHCP MUST attempt to use DHCP.
> >
> > ==> what does "in the absence of a router" mean? maybe this needs to be
> > made sl
Hi All,
I forgot other text that Pekka suggested, here is all of the text:
reword:
For those IPv6 nodes that implement DHCP, those nodes MUST use DHCP
upon the receipt of a Router Advertisement with the 'M' flag set (see
section 5.5.3 of RFC2462). In addition, in the absence of a route
Hi all,
Pekka Savola raised a few editorial fixes on the node requirements, but
this is somewhat more substantial, so I'd like to see if the WG is OK
with it.
reword:
For those IPv6 nodes that implement DHCP, those nodes MUST use DHCP
upon the receipt of a Router Advertisement with the 'M'
Hi all,
The 2nd paragraph in 4.6 looks like:
If an application is going to support Source-Specific Multicast,
it "SHOULD support MLDv2 but MAY support MLDv1 and conform to the
Source-Specific Multicast overview document [RFC3569]; refer to
Source-Specific Multicast architecture document fo
Jari,
> >>>In the IPsec section, you mention that other security issues
> >>>will be covered in the Security Considerations section, but
> >>>I don't see any issues here...
>
> There used to be some things, but they got removed because
> people felt that those things belong to the individual
>
Assigned as issue 30.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of ext
> [EMAIL PROTECTED]
> Sent: 20 November, 2003 07:45
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: Issue 29: AD REVIEW: IPv6 Node Requirements
>
Jean-Jacques,
> I think that running MLDv1 on a host has consequences on other hosts
> on the same link : if a host send a MLDv1 report for a group G,
> then the router (Querier) must run in MLDv1 compatibility mode.
> In effect, this prevents other hosts on the same link to use MLDv2
> and sour
Eric,
Take your argument to the people opposing the Hain/Templin draft, because
your point is clearly made in that document.
Brian
EricLKlein wrote:
>
> Margaret.Wasserman wrote
> > > I have been speaking to different
> > > companies here in Israel, and the basic answer is that if I
> > > ca
41 matches
Mail list logo
