Subject: IPv6 WWW service

From: FAHAD ALI KHAN <[email-masked]>
Date: Tue, 24 Nov 2009 12:31:31 +0500

Guys … sorry if this email is not suit for this forum.

I have setup Dual stack web server, running personal blog. I have applied
for IPv6 Forum – IPv6 enabled WWW logo program, but it shows IPv6 HTTP
access test was failed, whereas in my opinion & testing its UP & Running. I
wish if anyone on IPv6 please check fahad.xpedientonline.net is available or
not.

Initially I feel it might be the MTU issue, but I have set both router &
server interface’s MTU to 1280B (which is on Native v6) and Router is than
Tunnel to IPv6 ISP in UK (Tunnel IPv6 MTU is 1480). Can anyone suggest me,
where I am lacking?

If replies are not suitable for this forum than please check & reply to me
directly.

I hope, ppls will help me to solve this.

* *

*Regards*

* *

*Fahad*

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 24 Nov 2009 08:59:03 +0100 (CET)

> wish if anyone on IPv6 please check fahad.xpedientonline.net is available or

There is no AAAA record.

$ dig +short ANY fahad.xpedientonline.net
124.29.205.182
$ dig +short AAAA fahad.xpedientonline.net
$

So no IPv6 for you until this is fixed.

Also, I don't think this forum is the right one for basic IPv6 help, 
[email-masked] and [email-masked] is 
probably better.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Eddie Parra <[email-masked]>
Date: Tue, 24 Nov 2009 08:14:15 -0800

It works now...

eparra@isp-gw2> telnet 2001:4538:100::2 port 80
Trying 2001:4538:100::2...
Connected to 2001:4538:100::2.
Escape character is '^]'.
GET
<html><body><h1><p align=center>Restricted Access</p></h1>
<p align=center>
Directory browsing is not permitted.
</p>
<p align=center>
Please contact [email-masked]<mailto:[email-masked]> if you feel you have reached this page in error.
</p>
</body></html>

Connection closed by foreign host.

eparra@isp-gw2>

-Eddie

On Nov 23, 2009, at 11:59 PM, Mikael Abrahamsson wrote:

wish if anyone on IPv6 please check fahad.xpedientonline.net<http://fahad.xpedientonline.net> is available or
not.

There is no AAAA record.

$ dig +short ANY fahad.xpedientonline.net<http://fahad.xpedientonline.net>
124.29.205.182
$ dig +short AAAA fahad.xpedientonline.net<http://fahad.xpedientonline.net>
$

Also, I don't think this forum is the right one for basic IPv6 help,
[email-masked]<mailto:[email-masked]> and [email-masked]<mailto:[email-masked]> is
probably better.

--
Mikael Abrahamsson    email: [email-masked]<mailto:[email-masked]>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Nov 2009 09:48:50 -0800

Hello 6man,

I have posted a new draft titled:

  "Stub Router Advertisements in IPv6 Neighbor Discovery"
  http://tools.ietf.org/search/draft-templin-6man-stub-router

The main idea is that RFC4861 specifies the operation of
routers wrt sending and receiving Router Advertisements
(RAs), but it makes no distinction between different
classes of routers that may occur on a link. This document
identifies two classes of routers: 1) those that connect
a link to a provider network, and are thus "authoritative"
for the link, and 2) those that connect stub networks to
the link but do not directly connect the link to a
provider network.

This latter class of routers is not discussed in RFC4861,
but the present document provides an analysis of the
conditions under which a stub router may send RAs and
specifies the information that stub routers may include
in their RAs.

I would like to see this document considered as a work
item under the 6man wg, and I would welcome any comments
and discussion on the draft.

Thanks - Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Nov 2009 10:27:42 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Tuesday, November 24, 2009 9:49 AM
> To: [email-masked]
> Subject: New draft on "Stub Router Advertisements in IPv6 Neighbor Discovery"
> 
> Hello 6man,
> 

Sorry; it looks like this link isn't working. Please
try this one:

http://tools.ietf.org/search/draft-templin-6man-stub-router-00

Fred

> [email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Tue, 24 Nov 2009 14:37:01 -0500

Fred,

Can you summarize what problem this draft is aimed  at solving? What
is the motivation for this draft? (I've read it, but I don't
understand what the benefit of this approach is or what problem it
solves.)

Thomas

---

From: Bob Hinden <[email-masked]>
Date: Tue, 24 Nov 2009 14:51:39 -0800

> understand what the benefit of this approach is or what problem it

In the Introduction says:

   A stub router is any router that attaches stub networks to the link,
   but does not itself attach the link to a provider network.  Here, a
   "stub network" could be as simple as a small collection of IPv6
   links, or as large as a complex corporate enterprise network.  Stub
   routers are said to be "non-authoritative" for the link, since they
   cannot themselves provide forwarding services for packets emanating
   from their stub networks without using another router on the link as
   a transit.

I disagree with this and don't think that a router that is connected to an ISP is inherrently higher priority than other routers.  This is definitely not true in enterprise networks.  

We have other ways of doing this in a more general fashion such as RFC4191 "Default Router Preferences and More-Specific Routes".  I don't see any need to define "stub routers" and see a lot of harm doing so.  For example, in an enterprise, routing may be setup to keep the traffic inside of the enterprise for a long as possible and not use the local ISP connection.  The inter-enterprise links might be much faster.

Bob

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 25 Nov 2009 08:29:01 -0800

Thomas,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Narten
> Sent: Tuesday, November 24, 2009 11:37 AM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: New draft on "Stub Router Advertisements in IPv6 NeighborDiscovery"
> 
> Fred,
> 

When a stub router connects a stub network to a link,
it needs to somehow be provisioned with one or more
default routes pointing to other routers on the link
that can forward packets on toward a provider network.
The normal IPv6 ND mechanism for this is RS/RA, but
if the stub router were to send an RS the routers that
receive it would immediately set 'isrouter' to FALSE
and we don't want that.

At the same time, the stub router may need to publish
its prefixes with other routers, and it can do so by
including RFC4191 Route Information Options in the
RAs that it sends.

A valid question is why not just run a routing protocol
between all the routers on the link? That may be the
preferred method in some cases, but when there are many,
many routers on the link the control overhead would be
excessive when only a few default routes are needed.
Also, discovery of other routers on the link in order
to bootstrap neighbor relationships may be difficult
to automate on links such as NBMA.

But the simplest explanation is that RFC4861 currently
says that routers send RAs irrespective of whether/not
they are authoritative for the link. So, this spec
updates RFC4861 by specifying appropriate limits on
the information stub routers may include in their RAs.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 25 Nov 2009 08:47:04 -0800

Hi Bob,

> From: Bob Hinden [mailto:[email-masked]]
> Sent: Tuesday, November 24, 2009 2:52 PM
> To: Thomas Narten
> Cc: Bob Hinden; Templin, Fred L; [email-masked]
> Subject: Re: New draft on "Stub Router Advertisements in IPv6 Neighbor Discovery"
> 
> 
> I disagree with this and don't think that a router that is connected to an ISP is inherrently higher
> priority than other routers.

I don't understand this comment. The entity I am calling
"stub router" is simply trying to find a way to forward
packets on to their final destination using the best
possible exit router. There is nothing said or implied
about "priority".

> This is definitely not true in enterprise networks.

This is actually all about enterprise networks; in some ways,
an ISP network can be seen as just a special case of an
Enterprise network.

> We have other ways of doing this in a more general fashion such as RFC4191 "Default Router
> Preferences and More-Specific Routes".

Exactly; this document very much expects that stub routers
will advertise RFC4191 more-specific routers.

> I don't see any need to define "stub routers" and see a lot
> of harm doing so.  For example, in an enterprise, routing may be setup to keep the traffic inside of
> the enterprise for a long as possible and not use the local ISP connection.  The inter-enterprise
> links might be much faster.

The way it works is that the stub router may have a default
route but may not have a more-specific route to the destination
inside the enterprise. It then sends the packet to a default
router which hairpins it back to a router within the enterprise
that aggregates the more-specific route, but also sends a
redirect back to the stub router that originated the packet.
The stub router then sends an RA to the enterprise router
that aggregates the more-specific route, then subsequent
packets flow through the more-specific route and eliminate
the dogleg.

So yes; packets stay inside the enterprise and do not go out
the local ISP connection only to come back in again.

Fred

---

From: Narasimhan Venkataramaiah <[email-masked]>
Date: Wed, 25 Nov 2009 22:48:34 +0000

Is the authoritative router supposed to publish the stub router's more specific routes (learnt from the route info options in the stub router's RA) in its routing protocol? If so the security issues with this are much severe than the link local security issues of RFC 4861. If not - then the stub router cannot publish its more specific routes broadly - thus limiting its use.

Simha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Tuesday, November 24, 2009 10:28 AM
To: [email-masked]
Subject: RE: New draft on "Stub Router Advertisements in IPv6 Neighbor Discovery"

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 30 Nov 2009 09:08:30 -0800

Hi Simha,

Thanks for your comments, and see below:

> From: Narasimhan Venkataramaiah [mailto:[email-masked]]
> Sent: Wednesday, November 25, 2009 2:49 PM
> To: Templin, Fred L; [email-masked]
> Subject: RE: New draft on "Stub Router Advertisements in IPv6 NeighborDiscovery"
> 
> Is the authoritative router supposed to publish the stub router's more specific routes (learnt from
> the route info options in the stub router's RA) in its routing protocol?

Yes; the authoritative router both populates its FIB with
the more-specifics and publishes the more-specifics, e.g.,
via a dynamic routing protocol.

> If so the security issues
> with this are much severe than the link local security issues of RFC 4861.

Right, and this could be addressed in a brief passage under
Security Considerations. Please check the following:

   "7.  Security Considerations
 
      The security considerations in [RFC4191][RFC4861] apply. In
      addition, authoritative routers must be provisioned with
      proof-of-ownership of any prefixes in Route Information
      Options (RIOs) advertised by stub routers. SEcure Neighbor
      Discovery (SEND; [RFC3971]) provides an example mechanism
      whereby stub routers can provide prefix proof-of-ownership."

> If not - then the stub
> router cannot publish its more specific routes broadly - thus limiting its use.

As above, we will want to provide full support for stub routers
advertising RFC4191 RIOs and not limit their applicability. 

>From a broader perspective, can you comment as to whether this
approach looks useful?

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 30 Nov 2009 11:53:15 -0800

Bob and Thomas,

Have my responses wrt your comments cleared up the concerns
to the point that this document can be considered as a 6man
working group item to update RFC4861?

Thanks - Fred

> Sent: Wednesday, November 25, 2009 8:47 AM
> To: Bob Hinden; Thomas Narten
> Cc: [email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Mon, 30 Nov 2009 12:14:30 -0800

Fred,

> working group item to update RFC4861?

No, we would have to see more support from the working group before it could be considered a working group document.  You could ask for a slot at the next IETF meeting if you wish.

Bob

---

From: Mark Smith <[email-masked]>
Date: Tue, 1 Dec 2009 09:01:23 +1030

Hi Fred,

On Wed, 25 Nov 2009 08:47:04 -0800

> the local ISP connection only to come back in again.

I've been thinking of something similar if not the same. With some ISP
customer attachment models e.g. certain ADSL ones, it'd be
possible to have 100s or 1000s of subscriber CPE in a common link
segment using one or a couple of upstream provider routers. Without
something like a prefix redirect, hair pinning would occur for traffic
between the downstream subscriber CPE, which could be a significant
amount of traffic if there is a lot of downstream CPE and the
subscribers are using applications that tend towards traffic locality
e.g. VoIP and Video between relatives in the same geographically area,
game players, P2P architecture applications etc. 

There can be some cost advantages to ISPs to aggregate
customers into multiple layer 2 geographic groups (e.g. a central
office/telephone exchange), and then have routing performed at a more
central off-site location. It'd be useful to have a mechanism to try to
keep traffic within the same c.o./exchange, minimising the use of the
more costly backhaul bandwidth and upstream "one-armed-router" interface
bandwidth when possible. Latency would also be reduced.

When I've brought this idea up before (I think in v6ops), one concern
was how it would impact the ability of an ISP to perform lawful
intercept. The concern was that as the provider router wouldn't see the
downstream inter-CPE traffic, LI wouldn't be able to be performed. My
answer is that LI seems to be best achieved when it is performed as
close as possible to the lawfully intercepted subscriber as
possible. In this shared segment multiple-subscriber CPE/upstream
provider router model, LI would be best performed at the point of
attachment for the individual CPE/subscriber e.g. the point where the
individual CPE's ADSL service attaches to the service provider's
network. To do that, the ISP would need administrative control at and
over that point of attachment. If the ISP doesn't have control of that
point of attachment, then this LI can't be achieved with this
prefix redirected, shared-segment CPE model - meaning that a different
connectivity model e.g. PPPoE for the subscribers, with the
resulting drawback of hair pinning, needs to be used. In other words,
this connectivity model is an alternative connectivity option, with
possible traffic locality benefits, if an ISP owns or is in control of
both the layer 2 and layer 3 infrastructure.

I think it'd be useful if this draft or associated ones provided a
mechanism applicable to this ISP scenario.

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 30 Nov 2009 15:11:47 -0800

Mark,

Thanks for the comments, and see below:

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Smith
> Sent: Monday, November 30, 2009 2:31 PM
> To: Templin, Fred L
> Cc: Thomas Narten; [email-masked]; Bob Hinden

ISP customer attachment models is certainly one domain of
applicability that is in scope.
 
> bandwidth when possible. Latency would also be reduced.

"Router-on-a-stick" is another way I have seen it mentioned.
But yes, partitioning into multiple L2 groups is a good idea.
 
> both the layer 2 and layer 3 infrastructure.

The lawful intercept question is an interesting one, but
as you say if the ISP owns both the L2 and L3 infrastucture
there should be a way to support it. It may be much more
challenging to do the intercept from L2 switches located
close to the CPEs, however, since you may need many points
of intercept in order to watch all CPEs. 

> mechanism applicable to this ISP scenario.

OK. Thanks.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 30 Nov 2009 17:30:37 -0800

Bob,

> Sent: Monday, November 30, 2009 12:15 PM
> To: Templin, Fred L
> Cc: Bob Hinden; Thomas Narten; [email-masked]
> No, we would have to see more support from the working group before it could be considered a working
> group document.  You could ask for a slot at the next IETF meeting if you wish.

An alternative is that this could be written up in an
"IPv6-over-foo" document that might have a more pressing
need for what I am calling "stub router advertisements"
than would be the case for other IPv6 links. But, two
factors that might suggest a standalone document are:

- there is a need to procure two new flag bits in
  Router Advertisement messages

- at a minimum, it seems like there should something
  said about the sort of information that a stub router
  MUST NOT include in any RAs it sends. In particular,
  it must not include any information that would
  override the information advertised by routers that
  are authoritative for the link.

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 01 Dec 2009 14:52:30 +1300

>> mechanism applicable to this ISP scenario.

However, the IETF policy stated in RFC2804 says

"1. Summary position

   The IETF has decided not to consider requirements for wiretapping as
   part of the process for creating and maintaining IETF standards."

so while this issue may affect actual deployment scenarios, it can't
directly affect our protocol design requirements here.

(I would suggest that statements of agreement or disagreement with
this IETF policy don't belong on this list.)

    Brian

---

From: Mark Smith <[email-masked]>
Date: Tue, 1 Dec 2009 13:26:02 +1030

Hi Brian,

On Tue, 01 Dec 2009 14:52:30 +1300

> directly affect our protocol design requirements here.

I think a "prefix redirect" mechanism is justified because it provides
more optimal forwarding for inter-CPE traffic. I only brought up
the LI issue and addressed it because that seemed to be the only
objection there was to the idea when I suggested it before. I don't
think it is a valid concern, and if the IETF has decided not to
consider LI type requirements, then it is one less thing any drafts have
to address and document.

Regards,
Mark.