headers
Mark.Andrews | 1 Oct 2003 01:50

Re: help


> Hi all 
> I m new to IPv6. Can anybody answer the following question, so that I could b
> etter understand IPv6 :
>  
> Is fragmentaion is possible in IPv6 Packet/datagram ?? if Yes then how ??? if
>  No. then why not ???

	See RFC 2460.

	http://www.ietf.org/html.charters/ipv6-charter.html

	Also please do not send HTML to the list.

> Thanx
>  
> ahj
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews <at> isc.org

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Andrew White | 1 Oct 2003 03:00

Re: Comments on draft-hain-templin-ipv6-limitedrange-02.txt

As the originator of section 4.8, I'll speak to this one...

Fred Templin wrote:
> 
> > 4.8 I'm afraid I couldn't understand this scenario at all.  When the
> > two sites connect, do they essentially merge into a single,
> > multi-homed site?
> 
> I believe the answer to this is yes, and I believe Brian Haberman
> also expressed concerns about such scenarios since they touch on
> site multi-homing. (My answer to Brian is that we are not trying
> to re-create RFC 3582 in this document.) What you would suggest
> in terms of this block of text?

I don't think it's possible to completely divorce local addressing from
multi-homing, unless we want to go down the NAT path (any takers?  No, I
thought not).

One local addressing model that both Tony and I have been envisioning (and
IMO the most compelling) is that of disjoint, overlapping addressing
spaces.  The local network uses an internal addressing scheme for all
internal operations.  When and if 'external' connectivity is applied (which
may be another 'local' network) the external space is also made available to
all nodes within the network that want external operation.  Local nodes are
configured to prefer the internal addresses for internal use and the global
addresses for destinations that don't have a matching internal address.

Note that the 'internal' addresses could be global unicast addresses or
'local' addresses.  Likewise the 'external' addresses, although these will
probably be global.  The key issue is that the 'internal' addresses are
(Continue reading)

Permalink | Reply | 1 comment |
headers
john.loughney | 1 Oct 2003 05:57
Picon

RE: Node Req: Issue27: 11. Security Considerations

Hi Thomas,

I'll remove the text.

John

> -----Original Message-----
> From: ext Thomas Narten [mailto:narten <at> us.ibm.com]
> Sent: 30 September, 2003 13:50
> To: Loughney John (NRC/Helsinki)
> Cc: ipv6 <at> ietf.org; jari.arkko <at> kolumbus.fi
> Subject: Re: Node Req: Issue27: 11. Security Considerations 
> 
> 
> > Your comments at the end of this mail confused me.  Do you 
> want the text
> > removed or do you want clarifying text?
> 
> I'm fine with removing it. My last point was more about if it's felt
> the text needs to stay.
> 
> Thomas
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 5 comments |
headers
john.loughney | 1 Oct 2003 06:03
Picon

RE: Node Req: Issue26: 9.1.1 IPv6 Router Alert Option - RFC2711

Hi Thomas,

The text looks good, I'll add it.

thanks,
John

> -----Original Message-----
> From: ext Thomas Narten [mailto:narten <at> us.ibm.com]
> Sent: 29 September, 2003 21:16
> To: Loughney John (NRC/Helsinki)
> Cc: ipv6 <at> ietf.org
> Subject: Re: Node Req: Issue26: 9.1.1 IPv6 Router Alert 
> Option - RFC2711
> 
> 
> 
> john.loughney <at> nokia.com writes:
> 
> > Reading 2711, there are some host / server specific issues 
> about 2711. 
> > Suggested text:
> 
> >   IPv6 Router Alert Option specific [RFC-2711] defines a 
> new option in the
> 
> s/specific/specifically/?
> >   IPv6 Hop-by-Hop Header. Hosts MAY support the router alert option 
> >   defined. Nodes that generate RSVP message MUST implement 
> the router
(Continue reading)

Permalink | Reply | 4 comments |
headers
Chirayu Patel | 1 Oct 2003 07:23

ndproxy-00 (General comments)

Hello,

Few comments on draft-thaler-ipv6-ndproxy-00.txt.

CP

1. Section 1. First bullet following the first paragraph.

   The first bullet talks about an "access point". Give a reference to
   the 802.11 spec. Should 802.11 be mentioned in the first place? What
   advantage does ndproxy provide over classical bridges in an
   802.11 network?

2. Section 1. 2nd Paragraph. 

   Rephrase to:

   It is expected that whenever possible links will be bridged at the
   link layer using classic bridge technology.

   Bridging at the network layer SHOULD be used only when the classic
   bridges cannot be used. For bridging at the network layer, a single
   "bridge" interface will be exposed to the IP layer. In the
   remainder....

3. Remove the reference to MLSR, the document is no longer present in
   the I-D directory.

4. Section 1.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chirayu Patel | 1 Oct 2003 07:31

ndproxy-00 (new text + reorganization)

Hello,

After reading the complete document, I feel that there are a few pieces
that are still missing in the document.

Suggested reorganization
---------------------------

he document can do with some reorganization. Section 2 is a bit too
long. It needs to be broken up, and a few more sections should also be
added.

1) Introduction
2) Requirements for ND proxy
2.1) Non-requirements for the ND proxy
3) Behavior of the ND proxy
   <This section will contain the guidelines (as listed in my previous
   email)>
3.1) Parsing IPv4 packets
3.1.1) ARP packets
3.1.2) ICMPv4 packets
3.1.3) DHCPv4 packets
3.1.4) Other protocol packets    
3.1.4.1) Unicast packets
3.1.4.2) Multicast/Broadcast packets       
3.2) Parsing IPv6 packets
3.2.1) ICMPv6 packets
3.2.1.1) NS/NA packets
3.2.1.2) RS/RA packets
3.2.1.3) Redirect packet
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chirayu Patel | 1 Oct 2003 07:37

ndproxy-00 (new text + reorganization)

Hello,

After reading the complete document, I feel that there are a few pieces
that are still missing in the document.

Suggested reorganization
---------------------------

The document can do with some reorganization. Section 2 is a bit too
long. It needs to be broken up, and a few more sections should also be
added.

1) Introduction
2) Requirements for ND proxy
2.1) Non-requirements for the ND proxy
3) Behavior of the ND proxy
   <This section will contain the guidelines (as listed in my previous
   email)>
3.1) Parsing IPv4 packets
3.1.1) ARP packets
3.1.2) ICMPv4 packets
3.1.3) DHCPv4 packets
3.1.4) Other protocol packets    
3.1.4.1) Unicast packets
3.1.4.2) Multicast/Broadcast packets       
3.2) Parsing IPv6 packets
3.2.1) ICMPv6 packets
3.2.1.1) NS/NA packets
3.2.1.2) RS/RA packets
3.2.1.3) Redirect packet
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Haberman | 1 Oct 2003 14:33

Re: Comments on draft-hain-templin-ipv6-limitedrange-02.txt


Fred Templin wrote:

> Brian,
> 
> Thanks for sending the detailed comments. Will give a first-pass
> at them below, but may require a couple of iterations.
> 
> Fred
> ftemplin <at> iprg.nokia.com
> 
> Brian Haberman wrote:
> 
>>
>> [WG chair hat off]
>>
>> Below are my comments on the Hain/Templin draft.  Globally,
>> I think that these goals are worthwhile for the entire IPv6
>> protocol suite.  This type of functionality is needed in order
>> for people to feel comfortable migrating from v4 to v6.
>>
>>
>>>  Goals for an Addressing Scheme to Support Local Communications within
>>>                                  Sites
>>
>>
>>
>> The title still implies that these goals will be satisfied
>> by an addressing scheme rather than some other mechanism.  As
>> it has been noted in the past, some of these goals are not
(Continue reading)

Permalink | Reply | 1 comment |
headers
john.loughney | 1 Oct 2003 15:19
Picon

RE: Node Req: Issue22: 4.5.4 Default Address Selection for IPv6 - RFC3484 text

Hi Thomas,

I will make the changes.

John

> -----Original Message-----
> From: ext Thomas Narten [mailto:narten <at> us.ibm.com]
> Sent: 29 September, 2003 20:52
> To: Loughney John (NRC/Helsinki)
> Cc: ipv6 <at> ietf.org
> Subject: Re: Node Req: Issue22: 4.5.4 Default Address 
> Selection for IPv6
> - RFC3484 text 
> 
> 
> > > > 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, the rules specified in the document MUST be
> > > >  implemented. A node needs to belong to one site, 
> however there is no
> > > >  requirement that a node be able to belong to more than 
> one site.
> > >
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brian E Carpenter | 1 Oct 2003 16:22
Picon
Favicon

Re: Comments on draft-hain-templin-ipv6-limitedrange-02.txt

below...

Andrew White wrote:
> 
> As the originator of section 4.8, I'll speak to this one...
> 
> Fred Templin wrote:
> >
> > > 4.8 I'm afraid I couldn't understand this scenario at all.  When the
> > > two sites connect, do they essentially merge into a single,
> > > multi-homed site?
> >
> > I believe the answer to this is yes, and I believe Brian Haberman
> > also expressed concerns about such scenarios since they touch on
> > site multi-homing. (My answer to Brian is that we are not trying
> > to re-create RFC 3582 in this document.) What you would suggest
> > in terms of this block of text?
> 
> I don't think it's possible to completely divorce local addressing from
> multi-homing, unless we want to go down the NAT path (any takers?  No, I
> thought not).

Agreed. It would be rather tragic to define a new form of address to meet
the requirements in this draft, and another very similar new form of address
to meet multihoming requirements. It should be a goal to avoid this, and it
needs to be a shared goal of the ipv6 and multi6 WGs.

So I don't think it's possible to eliminate mention of multihoming from
this draft, but it should be mentioned mainly for this reason.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane